home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1045.txt < prev    next >
Text File  |  1994-08-01  |  265KB  |  7,131 lines

  1.  
  2.  
  3. Network Working Group                                     David Cheriton
  4. Request for Comments:  1045                          Stanford University
  5.                                                            February 1988
  6.  
  7.  
  8.               VMTP: VERSATILE MESSAGE TRANSACTION PROTOCOL
  9.                          Protocol Specification
  10.  
  11.  
  12.  
  13. STATUS OF THIS MEMO
  14.  
  15. This RFC describes a protocol proposed as a standard for the Internet
  16. community.  Comments are encouraged.  Distribution of this document is
  17. unlimited.
  18.  
  19.  
  20. OVERVIEW
  21.  
  22. This memo specifies the Versatile Message Transaction Protocol (VMTP)
  23. [Version 0.7 of 19-Feb-88], a transport protocol specifically designed
  24. to support the transaction model of communication, as exemplified by
  25. remote procedure call (RPC).  The full function of VMTP, including
  26. support for security, real-time, asynchronous message exchanges,
  27. streaming, multicast and idempotency, provides a rich selection to the
  28. VMTP user level.  Subsettability allows the VMTP module for particular
  29. clients and servers to be specialized and simplified to the services
  30. actually required.  Examples of such simple clients and servers include
  31. PROM network bootload programs, network boot servers, data sensors and
  32. simple controllers, to mention but a few examples.
  33.  
  34.  
  35.  
  36.  
  37. RFC 1045                       VMTP                        February 1988 
  38.  
  39.  
  40.                            Table of Contents
  41.  
  42. 1. Introduction                                                        1
  43.  
  44.    1.1. Motivation                                                     2
  45.        1.1.1. Poor RPC Performance                                     2
  46.        1.1.2. Weak Naming                                              3
  47.        1.1.3. Function Poor                                            3
  48.    1.2. Relation to Other Protocols                                    4
  49.    1.3. Document Overview                                              5
  50.  
  51. 2. Protocol Overview                                                   6
  52.  
  53.    2.1. Entities, Processes and Principals                             7
  54.    2.2. Entity Domains                                                 9
  55.    2.3. Message Transactions                                          10
  56.    2.4. Request and Response Messages                                 11
  57.    2.5. Reliability                                                   12
  58.        2.5.1. Transaction Identifiers                                 13
  59.        2.5.2. Checksum                                                14
  60.        2.5.3. Request and Response Acknowledgment                     14
  61.        2.5.4. Retransmissions                                         15
  62.        2.5.5. Timeouts                                                15
  63.        2.5.6. Rate Control                                            18
  64.    2.6. Security                                                      19
  65.    2.7. Multicast                                                     21
  66.    2.8. Real-time Communication                                       22
  67.    2.9. Forwarded Message Transactions                                24
  68.    2.10. VMTP Management                                              25
  69.    2.11. Streamed Message Transactions                                25
  70.    2.12. Fault-Tolerant Applications                                  28
  71.    2.13. Packet Groups                                                29
  72.    2.14. Runs of Packet Groups                                        31
  73.    2.15. Byte Order                                                   32
  74.    2.16. Minimal VMTP Implementation                                  33
  75.    2.17. Message vs. Procedural Request Handling                      33
  76.    2.18. Bibliography                                                 34
  77.  
  78. 3. VMTP Packet Formats                                                37
  79.  
  80.    3.1. Entity Identifier Format                                      37
  81.    3.2. Packet Fields                                                 38
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89. Cheriton                                                        [page i]
  90.  
  91.  
  92.  
  93. RFC 1045                       VMTP                        February 1988 
  94.  
  95.  
  96.    3.3. Request Packet                                                45
  97.    3.4. Response Packet                                               47
  98.  
  99. 4. Client Protocol Operation                                          49
  100.  
  101.    4.1. Client State Record Fields                                    49
  102.    4.2. Client Protocol States                                        51
  103.    4.3. State Transition Diagrams                                     51
  104.    4.4. User Interface                                                52
  105.    4.5. Event Processing                                              53
  106.    4.6. Client User-invoked Events                                    54
  107.        4.6.1. Send                                                    54
  108.        4.6.2. GetResponse                                             56
  109.    4.7. Packet Arrival                                                56
  110.        4.7.1. Response                                                58
  111.    4.8. Management Operations                                         61
  112.        4.8.1. HandleNoCSR                                             62
  113.    4.9. Timeouts                                                      64
  114.  
  115. 5. Server Protocol Operation                                          66
  116.  
  117.    5.1. Remote Client State Record Fields                             66
  118.    5.2. Remote Client Protocol States                                 66
  119.    5.3. State Transition Diagrams                                     67
  120.    5.4. User Interface                                                69
  121.    5.5. Event Processing                                              70
  122.    5.6. Server User-invoked Events                                    71
  123.        5.6.1. Receive                                                 71
  124.        5.6.2. Respond                                                 72
  125.        5.6.3. Forward                                                 73
  126.        5.6.4. Other Functions                                         74
  127.    5.7. Request Packet Arrival                                        74
  128.    5.8. Management Operations                                         78
  129.        5.8.1. HandleRequestNoCSR                                      79
  130.    5.9. Timeouts                                                      82
  131.  
  132. 6. Concluding Remarks                                                 84
  133.  
  134. I. Standard VMTP Response Codes                                       85
  135.  
  136. II. VMTP RPC Presentation Protocol                                    87
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145. Cheriton                                                       [page ii]
  146.  
  147.  
  148.  
  149. RFC 1045                       VMTP                        February 1988 
  150.  
  151.  
  152.    II.1. Request Code Management                                      87
  153.  
  154. III. VMTP Management Procedures                                       89
  155.  
  156.    III.1. Entity Group Management                                    100
  157.    III.2. VMTP Management Digital Signatures                         101
  158.  
  159. IV. VMTP Entity Identifier Domains                                   102
  160.  
  161.    IV.1. Domain 1                                                    102
  162.    IV.2. Domain 3                                                    104
  163.    IV.3. Other Domains                                               105
  164.    IV.4. Decentralized Entity Identifier Allocation                  105
  165.  
  166. V. Authentication Domains                                            107
  167.  
  168.    V.1. Authentication Domain 1                                      107
  169.    V.2. Other Authentication Domains                                 107
  170.  
  171. VI. IP Implementation                                                108
  172.  
  173. VII. Implementation Notes                                            109
  174.  
  175.    VII.1. Mapping Data Structures                                    109
  176.    VII.2. Client Data Structures                                     111
  177.    VII.3. Server Data Structures                                     111
  178.    VII.4. Packet Group transmission                                  112
  179.    VII.5. VMTP Management Module                                     113
  180.    VII.6. Timeout Handling                                           114
  181.    VII.7. Timeout Values                                             114
  182.    VII.8. Packet Reception                                           115
  183.    VII.9. Streaming                                                  116
  184.    VII.10. Implementation Experience                                 117
  185.  
  186. VIII. UNIX 4.3 BSD Kernel Interface for VMTP                         118
  187.  
  188. Index                                                                120
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201. Cheriton                                                      [page iii]
  202.  
  203.  
  204.  
  205. RFC 1045                       VMTP                        February 1988 
  206.  
  207.  
  208.                             List of Figures
  209.  
  210.    Figure 1-1:   Relation to Other Protocols                           4
  211.    Figure 3-1:   Request Packet Format                                45
  212.    Figure 3-2:   Response Packet Format                               47
  213.    Figure 4-1:   Client State Transitions                             52
  214.    Figure 5-1:   Remote Client State Transitions                      68
  215.    Figure III-1:   Authenticator Format                               92
  216.    Figure VII-1:   Mapping Client Identifier to CSR                  109
  217.    Figure VII-2:   Mapping Server Identifiers                        110
  218.    Figure VII-3:   Mapping Group Identifiers                         111
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257. Cheriton                                                       [page iv]
  258.  
  259. RFC 1045                       VMTP                        February 1988 
  260.  
  261.  
  262. 1. Introduction
  263.  
  264. The Versatile Message Transaction Protocol (VMTP) is a transport
  265. protocol designed to support remote procedure call (RPC) and general
  266. transaction-oriented communication.  By transaction-oriented
  267. communication, we mean that:
  268.  
  269.    - Communication is request-response:  A client sends a request
  270.      for a service to a server, the request is processed, and the
  271.      server responds.  For example, a client may ask for the next
  272.      page of a file as the service.  The transaction is terminated
  273.      by the server responding with the next page.
  274.  
  275.    - A transaction is initiated as part of sending a request to a
  276.      server and terminated by the server responding.  There are no
  277.      separate operations for setting up or terminating associations
  278.      between clients and servers at the transport level.
  279.  
  280.    - The server is free to discard communication state about a
  281.      client between transactions without causing incorrect behavior
  282.      or failures.
  283.  
  284. The term message transaction (or transaction) is used in the reminder of
  285. this document for a request-response exchange in the sense described
  286. above.
  287.  
  288. VMTP handles the error detection, retransmission, duplicate suppression
  289. and, optionally, security required for transport-level end-to-end
  290. reliability.
  291.  
  292. The protocol is designed to provide a range of behaviors within the
  293. transaction model, including:
  294.  
  295.    - Minimal two packet exchanges for short, simple transactions.
  296.  
  297.    - Streaming of multi-packet requests and responses for efficient
  298.      data transfer.
  299.  
  300.    - Datagram and multicast communication as an extension of the
  301.      transaction model.
  302.  
  303. Example Uses:
  304.  
  305.    - Page-level file access - VMTP is intended as the transport
  306.      level for file access, allowing simple, efficient operation on
  307.      a local network.  In particular, VMTP is appropriate for use
  308.      by diskless workstations accessing shared network file
  309.  
  310.  
  311. Cheriton                                                        [page 1]
  312.  
  313.  
  314.  
  315. RFC 1045                       VMTP                        February 1988 
  316.  
  317.  
  318.      servers.
  319.  
  320.    - Distributed programming - VMTP is intended to provide an
  321.      efficient transport level protocol for remote procedure call
  322.      implementations, distributed object-oriented systems plus
  323.      message-based systems that conform to the request-response
  324.      model.
  325.  
  326.    - Multicast communication with groups of servers to:  locate a
  327.      specific object within the group, update a replicated object,
  328.      synchronize the commitment of a distributed transaction, etc.
  329.  
  330.    - Distributed real-time control with prioritized message
  331.      handling, including datagrams, multicast and asynchronous
  332.      calls.
  333.  
  334. The protocol is designed to operate on top of a simple unreliable
  335. datagram service, such as is provided by IP.
  336.  
  337.  
  338. 1.1. Motivation
  339.  
  340. VMTP was designed to address three categories of deficiencies with
  341. existing transport protocols in the Internet architecture.  We use TCP
  342. as the key current transport protocol for comparison.
  343.  
  344.  
  345. 1.1.1. Poor RPC Performance
  346.  
  347. First, current protocols provide poor performance for remote procedure
  348. call (RPC) and network file access.  This is attributable to three key
  349. causes:
  350.  
  351.    - TCP requires excessive packets for RPC, especially for
  352.      isolated calls.  In particular, connection setup and clear
  353.      generates extra packets over that needed for VMTP to support
  354.      RPC.
  355.  
  356.    - TCP is difficult to implement, speaking purely from the
  357.      empirical experience over the last 10 years.  VMTP was
  358.      designed concurrently with its implementation, with focus on
  359.      making it easy to implement and providing sensible subsets of
  360.      its functionality.
  361.  
  362.    - TCP handles packet loss due to overruns poorly.  We claim that
  363.      overruns are the key source of packet loss in a
  364.      high-performance RPC environment and, with the increasing
  365.  
  366.  
  367. Cheriton                                                        [page 2]
  368.  
  369.  
  370.  
  371. RFC 1045                       VMTP                        February 1988 
  372.  
  373.  
  374.      performance of networks, will continue to be the key source.
  375.      (Older machines and network interfaces cannot keep up with new
  376.      machines and network interfaces.  Also, low-end network
  377.      interfaces for high-speed networks have limited receive
  378.      buffering.)
  379.  
  380. VMTP is designed for ease of implementation and efficient RPC.  In
  381. addition, it provides selective retransmission with rate-based flow
  382. control, thus addressing all of the above issues.
  383.  
  384.  
  385. 1.1.2. Weak Naming
  386.  
  387. Second, current protocols provide inadequate naming of transport-level
  388. endpoints because the names are based on IP addresses.  For example, a
  389. TCP endpoint is named by an Internet address and port identifier.
  390. Unfortunately, this makes the endpoint tied to a particular host
  391. interface, not specifically the process-level state associated with the
  392. transport-level endpoint.  In particular, this form of naming causes
  393. problems for process migration, mobile hosts and multi-homed hosts.
  394. VMTP provides host-address independent names, thereby solving the above
  395. mentioned problems.
  396.  
  397. In addition, TCP provides no security and reliability guarantees on the
  398. dynamically allocated names.  In particular, other than well-known
  399. ports, (host-addr, port-id)-tuples can change meaning on reboot
  400. following a crash.  VMTP provides large identifiers with guarantee of
  401. stability, meaning that either the identifier never changes in meaning
  402. or else remains invalid for a significant time before becoming valid
  403. again.
  404.  
  405.  
  406. 1.1.3. Function Poor
  407.  
  408. TCP does not support multicast, real-time datagrams or security.  In
  409. fact, it only supports pair-wise, long-term, streamed reliable
  410. interchanges.  Yet, multicast is of growing importance and is being
  411. developed for the Internet (see RFC 966 and 988).  Also, a datagram
  412. facility with the same naming, transmission and reception facilities as
  413. the normal transport level is a powerful asset for real-time and
  414. parallel applications.  Finally, security is a basic requirement in an
  415. increasing number of environments.  We note that security is natural to
  416. implement at the transport level to provide end-to-end security (as
  417. opposed to (inter)network level security).  Without security at the
  418. transport level, a transport level protocol cannot guarantee the
  419. standard transport level service definition in the presence of an
  420. intruder.  In particular, the intruder can interject packets or modify
  421.  
  422.  
  423. Cheriton                                                        [page 3]
  424.  
  425.  
  426.  
  427. RFC 1045                       VMTP                        February 1988 
  428.  
  429.  
  430. packets while updating the checksum, making mockery out of the
  431. transport-level claim of "reliable delivery".
  432.  
  433. In contrast, VMTP provides multicast, real-time datagrams and security,
  434. addressing precisely these weaknesses.
  435.  
  436. In general, VMTP is designed with the next generation of communication
  437. systems in mind.  These communication systems are characterized as
  438. follows.  RPC, page-level file access and other request-response
  439. behavior dominates.  In addition, the communication substrate, both
  440. local and wide-area, provides high data rates, low error rates and
  441. relatively low delay.  Finally, intelligent, high-performance network
  442. interfaces are common and in fact required to achieve performance that
  443. approximates the network capability.  However, VMTP is also designed to
  444. function acceptably with existing networks and network interfaces.
  445.  
  446.  
  447. 1.2. Relation to Other Protocols
  448.  
  449. VMTP is a transport protocol that fits into the layered Internet
  450. protocol environment.  Figure 1-1 illustrates the place of VMTP in the
  451. protocol hierarchy.
  452.  
  453.  
  454.  +-----------+ +----+ +-----------------+ +------+
  455.  |File Access| |Time| |Program Execution| |Naming|... Application
  456.  +-----------+ +----+ +-----------------+ +------+      Layer
  457.        |           |           |             |      |
  458.        +-----------+-----------+-------------+------+
  459.                                |
  460.                         +------------------+
  461.                         | RPC Presentation |          Presentation
  462.                         +------------------+          Layer
  463.                                   |
  464.             +------+          +--------+
  465.             |  TCP |          | VMTP   |              Transport
  466.             +------+          +--------+              Layer
  467.                 |                  |
  468.            +-----------------------------------+
  469.            |       Internet Protocol & ICMP    |      Internetwork
  470.            +-----------------------------------+      Layer
  471.  
  472.                Figure 1-1:   Relation to Other Protocols
  473.  
  474. The RPC presentation level is not currently defined in the Internet
  475. suite of protocols.  Appendix II defines a proposed RPC presentation
  476. level for use with VMTP and assumed for the definition of the VMTP
  477. management procedures.  There is also a need for the definition of the
  478.  
  479.  
  480. Cheriton                                                        [page 4]
  481.  
  482.  
  483.  
  484. RFC 1045                       VMTP                        February 1988 
  485.  
  486.  
  487. Application layer protocols listed above.
  488.  
  489. If internetwork services are not required, VMTP can be used without the
  490. IP layer, layered directly on top of the network or data link layers.
  491.  
  492.  
  493. 1.3. Document Overview
  494.  
  495. The next chapter gives an overview of the protocol, covering naming,
  496. message structure, reliability, flow control, streaming, real-time,
  497. security, byte-ordering and management.  Chapter 3 describes the VMTP
  498. packet formats.  Chapter 4 describes the client VMTP protocol operation
  499. in terms of pseudo-code for event handling.  Chapter 5 describes the
  500. server VMTP protocol operation in terms of pseudo-code for event
  501. handling.  Chapter 6 summarizes the state of the protocol, some
  502. remaining issues and expected directions for the future.  Appendix I
  503. lists some standard Response codes.  Appendix II describes the RPC
  504. presentation protocol proposed for VMTP and used with the VMTP
  505. management procedures.  Appendix III lists the VMTP management
  506. procedures.  Appendix IV proposes initial approaches for handling entity
  507. identification for VMTP.  Appendix V proposes initial authentication
  508. domains for VMTP.  Appendix VI provides some details for implementing
  509. VMTP on top of IP.  Appendix VII provides some suggestions on host
  510. implementation of VMTP, focusing on data structures and support
  511. functions.  Appendix VIII describes a proposed program interface for
  512. UNIX 4.3 BSD and its descendants and related systems.
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536. Cheriton                                                        [page 5]
  537.  
  538.  
  539.  
  540. RFC 1045                       VMTP                        February 1988 
  541.  
  542.  
  543. 2. Protocol Overview
  544.  
  545. VMTP provides an efficient, reliable, optionally secure transport
  546. service in the message transaction or request-response model with the
  547. following features:
  548.  
  549.    - Host address-independent naming with provision for multiple
  550.      forms of names for endpoints as well as associated (security)
  551.      principals.  (See Sections 2.1, 2.2, 3.1 and Appendix IV.)
  552.  
  553.    - Multi-packet request and response messages, with a maximum
  554.      size of 4 megaoctets per message.  (Sections 2.3 and 2.14.)
  555.  
  556.    - Selective retransmission. (Section 2.13.)  and rate-based flow
  557.      control to reduce overrun and the cost of overruns.  (Section
  558.      2.5.6.)
  559.  
  560.    - Secure message transactions with provision for a variety of
  561.      encryption schemes.  (Section 2.6.)
  562.  
  563.    - Multicast message transactions with multiple response messages
  564.      per request message.  (Section 2.7.)
  565.  
  566.    - Support for real-time communication with idempotent message
  567.      transactions with minimal server overhead and state (Section
  568.      2.5.3), datagram request message transactions with no
  569.      response, optional header-only checksum, priority processing
  570.      of transactions, conditional delivery and preemptive handling
  571.      of requests (Section 2.8)
  572.  
  573.    - Forwarded message transactions as an optimization for certain
  574.      forms of nested remote procedure calls or message
  575.      transactions.  (Section 2.9.)
  576.  
  577.    - Multiple outstanding (asynchronous) message transactions per
  578.      client.  (Section 2.11.)
  579.  
  580.    - An integrated management module, defined with a remote
  581.      procedure call interface on top of VMTP providing a variety of
  582.      communication services (Section 2.10.)
  583.  
  584.    - Simple subset implementation for simple clients and simple
  585.      servers.  (Section 2.16.)
  586.  
  587. This chapter provides an overview of the protocol as introduction to the
  588. basic ideas and as preparation for the subsequent chapters that describe
  589. the packet formats and event processing procedures in detail.
  590.  
  591.  
  592. Cheriton                                                        [page 6]
  593.  
  594.  
  595.  
  596. RFC 1045                       VMTP                        February 1988 
  597.  
  598.  
  599. In overview, VMTP provides transport communication between network-
  600. visible entities via message transactions.  A message transaction
  601. consists of a request message sent by the client, or requestor, to a
  602. group of server entities followed by zero or more response messages to
  603. the client, at most one from each server entity.  A message is
  604. structured as a message control portion and a segment data portion.  A
  605. message is transmitted as one or more packet groups.  A packet group  is
  606. one or more packets (up to a maximum of 32 packets) grouped by the
  607. protocol for acknowledgment, sequencing, selective retransmission and
  608. rate control.
  609.  
  610. Entities and VMTP operations are managed using a VMTP management
  611. mechanism that is accessed through a procedural interface (RPC)
  612. implemented on top of VMTP.  In particular, information about a remote
  613. entity is obtained and maintained using the Probe VMTP management
  614. operation.  Also, acknowledgment information and requests for
  615. retransmission are sent as notify requests to the management module.
  616. (In the following description, reference to an "acknowledgment" of a
  617. request or a response refers to a management-level notify operation that
  618. is acknowledging the request or response.)
  619.  
  620.  
  621. 2.1. Entities, Processes and Principals
  622.  
  623. VMTP defines and uses three main types of identifiers:  entity
  624. identifiers, process identifiers and principal identifiers, each 64-bits
  625. in length.  Communication takes place between network-visible entities,
  626. typically mapping to, or representing, a message port or procedure
  627. invocation.  Thus, entities are the VMTP communication endpoints.  The
  628. process associated with each entity designates the agent behind the
  629. communication activity for purposes of resource allocation and
  630. management.  For example, when a lock is requested on a file, the lock
  631. is associated with the process, not the requesting entity, allowing a
  632. process to use multiple entity identifiers to perform operations without
  633. lock conflict between these entities.  The principal associated with an
  634. entity specifies the permissions, security and accounting designation
  635. associated with the entity.  The process and principal identifiers are
  636. included in VMTP solely to make these values available to VMTP users
  637. with the security and efficiency provided by VMTP.  Only the entity
  638. identifiers are actively used by the protocol.
  639.  
  640. Entity identifiers are required to have three properties;
  641.  
  642. Uniqueness      Each entity identifier is uniquely defined at any given
  643.                 time.  (An entity identifier may be reused over time.)
  644.  
  645. Stability       An entity identifier does not change between valid
  646.  
  647.  
  648. Cheriton                                                        [page 7]
  649.  
  650.  
  651.  
  652. RFC 1045                       VMTP                        February 1988 
  653.  
  654.  
  655.                 meanings without suitable provision for removing
  656.                 references to the entity identifier.  Certain entity
  657.                 identifiers are strictly stable, (i.e. never changing
  658.                 meaning), typically being administratively assigned
  659.                 (although they need not be bound to a valid entity at
  660.                 all times), often called well-known identifiers.  All
  661.                 other entity identifiers are required to be T-stable,
  662.                 not change meaning without having remained invalid for
  663.                 at least a time interval T.
  664.  
  665. Host address independent
  666.                 An entity identifier is unique independent of the host
  667.                 address of its current host.  Moreover, an entity
  668.                 identifier is not tied to a single Internet host
  669.                 address.  An entity can migrate between hosts, reside on
  670.                 a mobile host that changes Internet addresses or reside
  671.                 on a multi-homed host.  It is up to the VMTP
  672.                 implementation to determine and maintain up to date the
  673.                 host addresses of entities with which it is
  674.                 communicating.
  675.  
  676. The stability of entity identifiers guarantees that an entity identifier
  677. represents the same logical communication entity and principal (in the
  678. security sense) over the time that it is valid.  For example, if an
  679. entity identifier is authenticated as having the privileges of a given
  680. user account, it continues to have those privileges as long as it is
  681. continuously valid (unless some explicit notice is provided otherwise).
  682. Thus, a file server need not fully authenticate the entity on every file
  683. access request.  With T-stable identifiers, periodically checking the
  684. validity of an entity identifier with period less than T seconds detects
  685. a change in entity identifier validity.
  686.  
  687. A group of entities can form an entity group, which is a set of zero or
  688. more entities identified by a single entity identifier.  For example,
  689. one can have a single entity identifier that identifies the group of
  690. name servers.  An entity identifier representing an entity group is
  691. drawn from the same name space as entity identifiers.  However, single
  692. entity identifiers are flagged as such by a bit in the entity
  693. identifier, indicating that the identifier is known to identify at most
  694. one entity.  In addition to the group bit, each entity identifier
  695. includes other standard type flags.  One flag indicates whether the
  696. identifier is an alias for an entity in another domain (See Section 2.2
  697. below.).  Another flag indicates, for an entity group identifier,
  698. whether the identifier is a restricted group or not.  A restricted group
  699. is one in which an entity can be added only by another entity with group
  700. management authorization.  With an unrestricted group, an entity is
  701. allowed to add itself.  If an entity identifier does not represent a
  702.  
  703.  
  704. Cheriton                                                        [page 8]
  705.  
  706.  
  707.  
  708. RFC 1045                       VMTP                        February 1988 
  709.  
  710.  
  711. group, a type bit indicates whether the entity uses big-endian or
  712. little-endian data representation (corresponding to Motorola 680X0 and
  713. VAX byte orders, respectively).  Further specification of the format of
  714. entity identifiers is contained in Section 3.1 and Appendix IV.
  715.  
  716. An entity identifier identifies a Client, a Server or a group of
  717. Servers <1>.  A Client is always identified by a T-stable identifier.  A
  718. server or group of servers may be identified by a a T-stable identifier
  719. (group or single entity) or by strictly stable (statically assigned)
  720. entity group identifier.  The same T-stable identifier can be used to
  721. identify a Client and Server simultaneously as long as both are
  722. logically associated with the same entity.  The state required for
  723. reliable, secure communication between entities is maintained in client
  724. state records (CSRs), which include the entity identifier of the Client,
  725. its principal, its current or next transaction identifier and so on.
  726.  
  727.  
  728. 2.2. Entity Domains
  729.  
  730. An entity domain is an administration or an administration mechanism
  731. that guarantees the three required entity identifier properties of
  732. uniqueness, stability and host address independence for the entities it
  733. administers.  That is, entity identifiers are only guaranteed to be
  734. unique and stable within one entity domain.  For example, the set of all
  735. Internet hosts may function as one domain.  Independently, the set of
  736. hosts local to one autonomous network may function as a separate domain.
  737. Each entity domain is identified by an entity domain identifier, Domain.
  738. Only entities within the same domain may communicate directly via VMTP.
  739. However, hosts and entities may participate in multiple entity domains
  740. simultaneously, possibly with different entity identifiers.  For
  741. example, a file server may participate in multiple entity domains in
  742. order to provide file service to each domain.  Each entity domain
  743. specifies the algorithms for allocation, interpretation and mapping of
  744. entity identifiers.
  745.  
  746. Domains are necessary because it does not appear feasible to specify one
  747. universal VMTP entity identification administration that covers all
  748. entities for all time.  Domains limit the number of entities that need
  749. to be managed to maintain the uniqueness and stability of the entity
  750.  
  751. _______________
  752.  
  753. <1>   Terms such as Client, Server, Request, Response, etc.  are
  754. capitalized in this document when they refer to their specific meaning
  755. in VMTP.
  756.  
  757.  
  758. Cheriton                                                        [page 9]
  759.  
  760.  
  761.  
  762. RFC 1045                       VMTP                        February 1988 
  763.  
  764.  
  765. name space.  Domains can also serve to separate entities of different
  766. security levels.  For instance, allocation of a unclassified entity
  767. identifier cannot conflict with secret level entity identifiers because
  768. the former is interpreted only in the unclassified domain, which is
  769. disjoint from the secret domain.
  770.  
  771. It is intended that there be a small number of domains.  In particular,
  772. there should be one (or a few) domains per installation "type", rather
  773. than per installation.  For example, the Internet is expected to use one
  774. domain per security level, resulting in at most 8 different domains.
  775. Cluster-based internetwork architectures, those with a local cluster
  776. protocol distinct from the wide-area protocol, may use one domain for
  777. local use and one for wide-area use.
  778.  
  779. Additional details on the specification of specific domains is provided
  780. in Appendix IV.
  781.  
  782.  
  783. 2.3. Message Transactions
  784.  
  785. The message transaction is the unit of interaction between a Client that
  786. initiates the transaction and one or more Servers.  A message
  787. transaction starts with a request message  generated by a client.  At
  788. the service interface, a server becomes involved with a transaction by
  789. receiving and accepting the request.  A server terminates its
  790. involvement with a transaction by sending a response message.  In a
  791. group message transaction, the server entity designated by the client
  792. corresponds to a group of entities.  In this case, each server in the
  793. group receives a copy of the request.  In the client's view, the
  794. transaction is terminated when it receives the response message or, in
  795. the case of a group message transaction, when it receives the last
  796. response message.  Because it is normally impractical to determine when
  797. the last response message has been received.  the current transaction is
  798. terminated by VMTP when the next transaction is initiated.
  799.  
  800. Within an entity domain, a transaction is uniquely identified by the
  801. tuple (Client, Transaction, ForwardCount).  where Transaction is a
  802. 32-bit number and ForwardCount is a 4-bit value.  A Client uses
  803. monotonically increasing Transaction identifiers for new message
  804. transactions.  Normally, the next higher transaction number, modulo
  805. 2**32, is used for the next message transaction, although there are
  806. cases in which it skips a small range of Transaction identifiers.  (See
  807. the description of the STI control flag.)  The ForwardCount is used when
  808. a message transaction is forwarded and is zero otherwise.
  809.  
  810. A Client generates a stream of message transactions with increasing
  811. transaction identifiers, directed at a diversity of Servers.  We say a
  812.  
  813.  
  814. Cheriton                                                       [page 10]
  815.  
  816.  
  817.  
  818. RFC 1045                       VMTP                        February 1988 
  819.  
  820.  
  821. Client has a transaction outstanding if it has invoked a message
  822. transaction, but has not received the last Response (or possibly any
  823. Response).  Normally, a Client has only one transaction outstanding at a
  824. time.  However, VMTP allows a Client to have multiple message
  825. transactions outstanding simultaneously, supporting streamed,
  826. asynchronous remote procedure call invocations.  In addition, VMTP
  827. supports nested calls where, for example, procedure A calls procedure B
  828. which calls procedure C, each on a separate host with different client
  829. entity identifiers for each call but identified with the same process
  830. and principal.
  831.  
  832.  
  833. 2.4. Request and Response Messages
  834.  
  835. A message transaction consists of a request message and one or more
  836. Response messages.  A message is structured as message control block
  837. (MCB) and segment data, passed as parameters, as suggested below.
  838.  
  839.   +-----------------------+
  840.   | Message Control Block |
  841.   +-----------------------+
  842.   +-----------------------------------+
  843.   |       segment data                |
  844.   +-----------------------------------+
  845.  
  846. In the request message, the MCB specifies control information about the
  847. request plus an optional data segment.  The MCB has the following
  848. format:
  849.   0                   1                   2                   3
  850.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  851.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  852.  +                         ServerEntityId  (8 octets)            +
  853.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  854.  |   Flags       |         RequestCode                           |
  855.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  856.  +                         CoresidentEntity (8 octets)           +
  857.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  858.  >                         User Data (12 octets)                 <
  859.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  860.  |                         MsgDelivery                           |
  861.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  862.  |                         SegmentSize                           |
  863.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  864.  
  865. The ServerEntityId is the entity to which the Request MCB is to be sent
  866. (or was sent, in the case of reception).  The Flags indicate various
  867. options in the request and response handling as well as whether the
  868.  
  869.  
  870. Cheriton                                                       [page 11]
  871.  
  872.  
  873. RFC 1045                       VMTP                        February 1988 
  874.  
  875.  
  876. CoresidentEntity, MsgDelivery and SegmentSize fields are in use.  The
  877. RequestCode field specifies the type of Request.  It is analogous to a
  878. packet type field of the Ethernet, acting as a switch for higher-level
  879. protocols.  The CoresidentEntity field, if used, designates a subgroup
  880. of the ServerEntityId group to which the Request should be routed,
  881. namely those members that are co-resident with the specified entity (or
  882. entity group).  The primary intended use is to specify the manager for a
  883. particular service that is co-resident with a particular entity, using
  884. the well-known entity group identifier for the service manager in the
  885. ServerEntityId field and the identifier for the entity in the
  886. CoresidentEntity field.  The next 12 octets are user- or
  887. application-specified.
  888.  
  889. The MsgDelivery field is optionally used by the RPC or user level to
  890. specify the portions of the segment data to transmit and on reception,
  891. the portions received.  It provides the client and server with
  892. (optional) access to, and responsibility for, a simple selective
  893. transmission and reception facility.  For example, a client may request
  894. retransmission of just those portions of the segment that it failed to
  895. receive as part of the original Response.  The primary intended use is
  896. to support highly efficient multi-packet reading from a file server.
  897. Exploiting user-level selective retransmission using the MsgDelivery
  898. field, the file server VMTP module need not save multi-packet Responses
  899. for retransmission.  Retransmissions, when needed, are instead handled
  900. directly from the file server buffers.
  901.  
  902. The SegmentSize field indicates the size of the data segment, if
  903. present.  The CoresidentEntity, MsgDelivery and SegmentSize fields are
  904. usable as additional user data if they are not otherwise used.
  905.  
  906. The Flags field provides a simple mechanism for the user level to
  907. communicate its use of VMTP options with the VMTP module as well as for
  908. VMTP modules to communicate this use among themselves.  The use of these
  909. options is generally fixed for each remote procedure so that an RPC
  910. mechanism using VMTP can treat the Flags as an integral part of the
  911. RequestCode field for the purpose of demultiplexing to the correct stub.
  912.  
  913. A Response message control block follows the same format except the
  914. Response is sent from the Server to the Client and there is no
  915. Coresident Entity field (and thus 20 octets of user data).
  916.  
  917.  
  918. 2.5. Reliability
  919.  
  920. VMTP provides reliable, sequenced transfer of request and response
  921. messages as well as several variants, such as unreliable datagram
  922. requests.  The reliability mechanisms include: transaction identifiers,
  923.  
  924.  
  925. Cheriton                                                       [page 12]
  926.  
  927.  
  928.  
  929. RFC 1045                       VMTP                        February 1988 
  930.  
  931.  
  932. checksums, positive acknowledgment of messages and timeout and
  933. retransmission of lost packets.
  934.  
  935.  
  936. 2.5.1. Transaction Identifiers
  937.  
  938. Each message transaction is uniquely identified by the pair (Client,
  939. Transaction).  (We defer discussion of the ForwardCount field to Section
  940. 2.9.)  The 32-bit transaction identifier is initialized to a random
  941. value when the Client entity is created or allocated its entity
  942. identifier.  The transaction identifier is incremented at the end of
  943. each message transaction.  All Responses with the same specified
  944. (Client, Transaction) pair are associated with this Request.
  945.  
  946. The transaction identifier is used for duplicate suppression at the
  947. Server.  A Server maintains a state record for each Client for which it
  948. is processing a Request, identified by (Client, Transaction).  A Request
  949. with the same (Client, Transaction) pair is discarded as a duplicate.
  950. (The ForwardCount field must also be equal.)  Normally, this record is
  951. retained for some period after the Response is sent, allowing the Server
  952. to filter out subsequent duplicates of this Request.  When a Request
  953. arrives and the Server does not have a state record for the sending
  954. Client, the Server takes one of three actions:
  955.  
  956.    1. The Server may send a Probe request, a simple query
  957.       operation, to the VMTP management module associated with the
  958.       requesting Client to determine the Client's current
  959.       Transaction identifier (and other information), initialize a
  960.       new state record from this information, and then process the
  961.       Request as above.
  962.  
  963.    2. The Server may reason that the Request must be a new request
  964.       because it does not have a state record for this Client if it
  965.       keeps these state records for the maximum packet lifetime of
  966.       packets in the network (plus the maximum VMTP retransmission
  967.       time) and it has not been rebooted within this time period.
  968.       That is, if the Request is not new either the Request would
  969.       have exceeded the maximum packet lifetime or else the Server
  970.       would have a state record for the Client.
  971.  
  972.    3. The Server may know that the Request is idempotent or can be
  973.       safely redone so it need not care whether the Request is a
  974.       duplicate or not.  For example, a request for the current
  975.       time can be responded to with the current time without being
  976.       concerned whether the Request is a duplicate.  The Response
  977.       is discarded at the Client if it is no longer of interest.
  978.  
  979.  
  980.  
  981. Cheriton                                                       [page 13]
  982.  
  983.  
  984.  
  985. RFC 1045                       VMTP                        February 1988 
  986.  
  987.  
  988. 2.5.2. Checksum
  989.  
  990. Each VMTP packet contains a checksum to allow the receiver to detect
  991. corrupted packets independent of lower level checks.  The checksum field
  992. is 32 bits, providing greater protection than the standard 16-bit IP
  993. checksum (in combination with an improved checksum algorithm).  The
  994. large packets, high packet rates and general network characteristics
  995. expected in the future warrant a stronger checksum mechanism.
  996.  
  997. The checksum normally covers both the VMTP header and the segment data.
  998. Optionally (for real-time applications), the checksum may apply only to
  999. the packet header, as indicated by the HCO control bit being set in the
  1000. header.  The checksum field is placed at the end of the packet to allow
  1001. it to be calculated as part of a software copy or as part of a hardware
  1002. transmission or reception packet processing pipeline, as expected in the
  1003. next generation of network interfaces.  Note that the number of header
  1004. and data octets is an integral multiple of 8 because VMTP requires that
  1005. the segment data be padded to be a multiple of 64 bits.  The checksum
  1006. field is appended after the padding, if any.  The actual algorithm is
  1007. described in Section 3.2.
  1008.  
  1009. A zero checksum field indicates that no checksum was transmitted with
  1010. the packet.  VMTP may be used without a checksum only when there is a
  1011. host-to-host error detection mechanism and the VMTP security facility is
  1012. not being used.  For example, one could rely on the Ethernet CRC if
  1013. communication is restricted to hosts on the same Ethernet and the
  1014. network interfaces are considered sufficiently reliable.
  1015.  
  1016.  
  1017. 2.5.3. Request and Response Acknowledgment
  1018.  
  1019. VMTP assumes an unreliable datagram network and internetwork interface.
  1020. To guarantee delivery of Requests and Response, VMTP uses positive
  1021. acknowledgments, retransmissions and timeouts.
  1022.  
  1023. A Request is normally acknowledged by receipt of a Response associated
  1024. with the Request, i.e. with the same (Client, Transaction).  With
  1025. streamed message transactions, it may also be acknowledged by a
  1026. subsequent Response that acknowledges previous Requests in addition to
  1027. the transaction it explicitly identifies.  A Response may be explicitly
  1028. acknowledged by a NotifyVmtpServer operation requested of the manager
  1029. for the Server.  In the case of streaming, this is a cumulative
  1030. acknowledgment, acknowledging all Responses with a lower transaction
  1031. identifier as well.)  In addition, with non-streamed communication, a
  1032. subsequent Request from the same Client acknowledges Responses to all
  1033. previous message transactions (at least in the sense that either the
  1034. client received a Response or is no longer interested in Responses to
  1035.  
  1036.  
  1037. Cheriton                                                       [page 14]
  1038.  
  1039.  
  1040.  
  1041. RFC 1045                       VMTP                        February 1988 
  1042.  
  1043.  
  1044. those earlier message transactions).  Finally, a client response timeout
  1045. (at the server) acknowledges a Response at least in the sense that the
  1046. server need not be prepared to retransmit the Response subsequently.
  1047. Note that there is no end-to-end guarantee of the Response being
  1048. received by the client at the application level.
  1049.  
  1050.  
  1051. 2.5.4. Retransmissions
  1052.  
  1053. In general, a Request or Response is retransmitted periodically until
  1054. acknowledged as above, up to some maximum number of retransmissions.
  1055. VMTP uses parameters RequestRetries(Server) and ResponseRetries(Client)
  1056. that indicate the number of retransmissions for the server and client
  1057. respectively before giving up.  We suggest the value 5 be used for both
  1058. parameters based on our experience with VMTP and Internet packet loss.
  1059. Smaller values (such as 3) could be used in low loss environments in
  1060. which fast detection of failed hosts or communication channels is
  1061. required.  Larger values should be used in high loss environments where
  1062. transport-level persistence is important.
  1063.  
  1064. In a low loss environment, a retransmission only includes the MCB and
  1065. not the segment data of the Request or Response, resulting in a single
  1066. (short) packet on retransmission.  The intended recipient of the
  1067. retransmission can request selective retransmission of all or part of
  1068. the segment data as necessary.  The selective retransmission mechanism
  1069. is described in Section 2.13.
  1070.  
  1071. If a Response is specified as idempotent, the Response is neither
  1072. retransmitted nor stored for retransmission.  Instead, the Client must
  1073. retransmit the Request to effectively get the Response retransmitted.
  1074. The server VMTP module responds to retransmissions of the Request by
  1075. passing the Request on to the server again to have it regenerate the
  1076. Response (by redoing the operation), rather than saving a copy of the
  1077. Response.  Only Request packets for the last transaction from this
  1078. client are passed on in this fashion; older Request packets from this
  1079. client are discarded as delayed duplicates.  If a Response is not
  1080. idempotent, the VMTP module must ensure it has a copy of the Response
  1081. for retransmission either by making a copy of the Response (either
  1082. physically or copy-on-write) or by preventing the Server from continuing
  1083. until the Response is acknowledged.
  1084.  
  1085.  
  1086. 2.5.5. Timeouts
  1087.  
  1088. There is one client timer for each Client with an outstanding
  1089. transaction.  Similarly, there is one server timer for each Client
  1090. transaction that is "active" at the server, i.e. there is a transaction
  1091.  
  1092.  
  1093. Cheriton                                                       [page 15]
  1094.  
  1095.  
  1096.  
  1097. RFC 1045                       VMTP                        February 1988 
  1098.  
  1099.  
  1100. record for a Request from the Client.
  1101.  
  1102. When the client transmits a new Request (without streaming), the client
  1103. timer  is set to roughly the time expected for the Response to be
  1104. returned.  On timeout, the Request is retransmitted with the APG
  1105. (Acknowledge Packet Group) bit set.  The timeout is reset to the
  1106. expected roundtrip time to the Server because an acknowledgment should
  1107. be returned immediately unless a Response has been sent.  The Request
  1108. may also be retransmitted in response to receipt of a VMTP management
  1109. operation indicating that selected portions of the Request message
  1110. segment need to be retransmitted.  With streaming, the timeout applies
  1111. to the oldest outstanding message transaction in the run of outstanding
  1112. message transactions.  Without streaming, there is one message
  1113. transaction in the run, reducing to the previous situation.  After the
  1114. first packet of a Response is received, the Client resets the timeout to
  1115. be the time expected before the next packet in the Response packet group
  1116. is received, assuming it is a multi-packet Response.  If not, the timer
  1117. is stopped.  Finally, the client timer is used to timeout waiting for
  1118. second and subsequent Responses to a multicast Request.
  1119.  
  1120. The client timer is set at different times to four different values:
  1121.  
  1122. TC1(Server)     The expected time required to receive a Response from
  1123.                 the Server.  Set on initial Request transmission plus
  1124.                 after its management module receives a NotifyVmtpClient
  1125.                 operation, acknowledging the Request.
  1126.  
  1127. TC2(Server)     The estimated round trip delay between the client and
  1128.                 the server.  Set when retransmitting after receiving no
  1129.                 Response for TC1(Server) time and retransmitting the
  1130.                 Request with the APG bit set.
  1131.  
  1132. TC3(Server)     The estimated maximum expected interpacket time for
  1133.                 multi-packet Responses from the Server.  Set when
  1134.                 waiting for subsequent Response packets within a packet
  1135.                 group before timing out.
  1136.  
  1137. TC4             The time to wait for additional Responses to a group
  1138.                 Request after the first Response is received.  This is
  1139.                 specified by the user level.
  1140.  
  1141. These values are selected as follows.  TC1 can be set to TC2 plus a
  1142. constant, reflecting the time within which most servers respond to most
  1143. requests.  For example, various measurements of VMTP usage at Stanford
  1144. indicate that 90 percent of the servers respond in less than 200
  1145. milliseconds.  Setting TC1 to TC2 + 200 means that most Requests receive
  1146. a Response before timing out and also that overhead for retransmission
  1147.  
  1148.  
  1149. Cheriton                                                       [page 16]
  1150.  
  1151.  
  1152.  
  1153. RFC 1045                       VMTP                        February 1988 
  1154.  
  1155.  
  1156. for long running transactions is insignificant.  A sophisticated
  1157. implementation may make the estimation of TC1 further specific to the
  1158. Server.
  1159.  
  1160. TC2 may be estimated by measuring the time from when a Probe request is
  1161. sent to the Server to when a response is received.  TC2 can also be
  1162. measured as the time between the transmission of a Request with the APG
  1163. bit set to receipt of a management operation acknowledging receipt of
  1164. the Request.
  1165.  
  1166. When the Server is an entity group, TC1 and TC2 should be the largest of
  1167. the values for the members of the group that are expected to respond.
  1168. This information may be determined by probing the group on first use
  1169. (and using the values for the last responses to arrive).  Alternatively,
  1170. one can resort to default values.
  1171.  
  1172. TC3 is set initially to 10 times the transmission time for the maximum
  1173. transmission unit (MTU) to be used for the Response.  A sophisticated
  1174. implementation may record TC3 per Server and refine the estimate based
  1175. on measurements of actual interpacket gaps.  However, a tighter estimate
  1176. of TC3 only improves the reaction time when a packet is lost in a packet
  1177. group, at some cost in unnecessary retransmissions when the estimate
  1178. becomes overly tight.
  1179.  
  1180. The server timer, one per active Client, takes on the following values:
  1181.  
  1182. TS1(Client)     The estimated maximum expected interpacket time.  Set
  1183.                 when waiting for subsequent Request packets within a
  1184.                 packet group before timing out.
  1185.  
  1186. TS2(Client)     The time to wait to hear from a client before
  1187.                 terminating the server processing of a Request.  This
  1188.                 limits the time spent processing orphan calls, as well
  1189.                 as limiting how out of date the server's record of the
  1190.                 Client state can be.  In particular, TS2 should be
  1191.                 significantly less than the minimum time within which it
  1192.                 is reasonable to reuse a transaction identifier.
  1193.  
  1194. TS3(Client)     Estimated roundtrip time to the Client,
  1195.  
  1196. TS4(Client)     The time to wait after sending a Response (or last
  1197.                 hearing from a client) before discarding the state
  1198.                 associated with the Request which allows it to filter
  1199.                 duplicate Request packets and regenerate the Response.
  1200.  
  1201. TS5(Client)     The time to wait for an acknowledgment after sending a
  1202.                 Response before retransmitting the Response, or giving
  1203.  
  1204.  
  1205. Cheriton                                                       [page 17]
  1206.  
  1207.  
  1208.  
  1209. RFC 1045                       VMTP                        February 1988 
  1210.  
  1211.  
  1212.                 up (after some number of retransmissions).
  1213.  
  1214. TS1 is set the same as TC3.
  1215.  
  1216. The suggested value for TS2 is TC1 + 3*TC2 for this server, giving the
  1217. Client time to timeout waiting for a Response and retransmit 3 Request
  1218. packets, asking for acknowledgments.
  1219.  
  1220. TS3 is estimated the same as TC1 except that refinements to the estimate
  1221. use measurements of the Response-to-acknowledgment times.
  1222.  
  1223. In the general case, TS4 is set large enough so that a Client issuing a
  1224. series of closely-spaced Requests to the same Server reuses the same
  1225. state record at the Server end and thus does not incur the overhead of
  1226. recreating this state.  (The Server can recreate the state for a Client
  1227. by performing a Probe on the Client to get the needed information.)  It
  1228. should also be set low enough so that the transaction identifier cannot
  1229. wrap around and so that the Server does not run out of CSR's.  We
  1230. suggest a value in the range of 500 milliseconds.  However, if the
  1231. Server accepts non-idempotent Requests from this Client without doing a
  1232. Probe on the Client, the TS4 value for this CSR is set to at least 4
  1233. times the maximum packet lifetime.
  1234.  
  1235. TS5 is TS3 plus the expected time for transmission and reception of the
  1236. Response.  We suggest that the latter be calculated as 3 times the
  1237. transmission time for the Response data, allowing time for reception,
  1238. processing and transmission of an acknowledgment at the Client end.  A
  1239. sophisticated implementation may refine this estimate further over time
  1240. by timing acknowledgments to Responses.
  1241.  
  1242.  
  1243. 2.5.6. Rate Control
  1244.  
  1245. VMTP is designed to deal with the present and future problem of packet
  1246. overruns.  We expect overruns to be the major cause of dropped packets
  1247. in the future.  A client is expected to estimate and adjust the
  1248. interpacket gap times so as to not overrun a server or intermediate
  1249. nodes.  The selective retransmission mechanism allows the server to
  1250. indicate that it is being overrun (or some intermediate point is being
  1251. overrun).  For example, if the server requests retransmission of every
  1252. Kth block, the client should assume overrun is taking place and increase
  1253. the interpacket gap times.  The client passes the server an indication
  1254. of the interpacket gap desired for a response.  The client may have to
  1255. increase the interval because packets are being dropped by an
  1256. intermediate gateway or bridge, even though it can handle a higher rate.
  1257. A conservative policy is to increase the interpacket gap whenever a
  1258. packet is lost as part of a multi-packet packet group.
  1259.  
  1260.  
  1261. Cheriton                                                       [page 18]
  1262.  
  1263.  
  1264.  
  1265. RFC 1045                       VMTP                        February 1988 
  1266.  
  1267.  
  1268. The provision of selective retransmission allows the rate of the client
  1269. and the server to "push up" against the maximum rate (and thus lose
  1270. packets) without significant penalty.  That is, every time that packet
  1271. transmission exceeds the rate of the channel or receiver, the recovery
  1272. cost to retransmit the dropped packets is generally far less than
  1273. retransmitting from the first dropped packet.
  1274.  
  1275. The interpacket gap is expressed in 1/32nd's of the MTU packet
  1276. transmission time.  The minimum interpacket gap is 0 and the maximum gap
  1277. that can be described in the protocol is 8 packet times.  This places a
  1278. limit on the slowest receivers that can be efficiently used on a
  1279. network, at least those handling multi-packet Requests and Responses.
  1280. This scheme also limits the granularity of adjustment.  However, the
  1281. granularity is relative to the speed of the network, as opposed to an
  1282. absolute time.  For entities on different networks of significantly
  1283. different speed, we assume the interconnecting gateways can buffer
  1284. packets to compensate<2>. With different network speeds and intermediary
  1285. nodes subject to packet loss, a node must adjust the interpacket gap
  1286. based on packet loss.  The interpacket gap parameter may be of limited
  1287. use.
  1288.  
  1289.  
  1290. 2.6. Security
  1291.  
  1292. VMTP provides an (optional) secure mode that protects against the usual
  1293. security threats of peeking, impostoring, message tampering and replays.
  1294. Secure VMTP must be used to guarantee any of the transport-level
  1295. reliability properties unless it is guaranteed that there are no
  1296. intruders or agents that can modify packets and update the packet
  1297. checksums.  That is, non-secure VMTP provides no guarantees in the
  1298. presence of an intelligent intruder.
  1299.  
  1300. The design closely follows that described by Birrell [1].  Authenticated
  1301. information about a remote entity, including an encryption/decryption
  1302. key, is obtained and maintained using a VMTP management operation, the
  1303. authenticated Probe operation, which is executed as a non-secure VMTP
  1304. message transaction.  If a server receives a secure Request for which
  1305. the server has no entity state, it sends a Probe request to the VMTP
  1306.  
  1307. _______________
  1308.  
  1309. <2>   Gateways must also employ techniques to preserve or intelligently
  1310. modify (if appropriate) the interpacket gaps.  In particular, they must
  1311. be sure not to arbitrarily remove interpacket gaps as a result of their
  1312. forwarding of packets.
  1313.  
  1314.  
  1315. Cheriton                                                       [page 19]
  1316.  
  1317.  
  1318.  
  1319. RFC 1045                       VMTP                        February 1988 
  1320.  
  1321.  
  1322. management module of the client, "challenging" it to provide an
  1323. authenticator that both authenticates the client as being associated
  1324. with a particular principal as well as providing a key for
  1325. encryption/decryption.  The principal can include a real and effective
  1326. principal, as used in UNIX <3>.  Namely, the real principal is the
  1327. principal on whose behalf the Request is being performed whereas the
  1328. effective principal is the principal of the module invoking the request
  1329. or remote procedure call.
  1330.  
  1331. Peeking is prevented by encrypting every Request and Response packet
  1332. with a working Key that is shared between Client and Server.
  1333. Impostoring and replays are detected by comparing the Transaction
  1334. identifier with that stored in the corresponding entity state record
  1335. (which is created and updated by VMTP as needed).  Message tampering is
  1336. detected by encryption of the packet including the Checksum field.  An
  1337. intruder cannot update the checksum after modifying the packet without
  1338. knowing the Key.  The cost of fully encrypting a packet is close to the
  1339. cost of generating a cryptographic checksum (and of course, encryption
  1340. is needed in the general case), so there is no explicit provision for
  1341. cryptographic checksum without packet encryption.
  1342.  
  1343. A Client determines the Principal of the Server and acquires an
  1344. authenticator for this Server and Principal using a higher level
  1345. protocol.  The Server cannot decrypt the authenticator or the Request
  1346. packets unless it is in fact the Principal expected by the Client.
  1347.  
  1348. An encrypted VMTP packet is flagged by the EPG bit  in the VMTP packet
  1349. header.  Thus, encrypted packets are easily detected and demultiplexed
  1350. from unencrypted packets.  An encrypted VMTP packet is entirely
  1351. encrypted except for the Client, Version, Domain, Length and Packet
  1352. Flags fields at the beginning of the packet.  Client identifiers can be
  1353. assigned, changed and used to have no real meaning to an intruder or to
  1354. only communicate public information (such as the host Internet address).
  1355. They are otherwise just a random means of identification and
  1356. demultiplexing and do not therefore divulge any sensitive information.
  1357. Further secure measures must be taken at the network or data link levels
  1358. if this information or traffic behavior is considered sensitive.
  1359.  
  1360. VMTP provides multiple authentication domains  as well as an encryption
  1361. qualifier to accommodate different encryption algorithms and their
  1362.  
  1363. _______________
  1364.  
  1365. <3>   Principal group membership must be obtained, if needed, by a
  1366. higher level protocol.
  1367.  
  1368.  
  1369. Cheriton                                                       [page 20]
  1370.  
  1371.  
  1372.  
  1373. RFC 1045                       VMTP                        February 1988 
  1374.  
  1375.  
  1376. corresponding security/performance trade-offs.  (See Appendix V.)  A
  1377. separate key distribution and authentication protocol is required to
  1378. handle generation and distribution of authenticators and keys.  This
  1379. protocol can be implemented on top of VMTP and can closely follow the
  1380. Birrell design as well.
  1381.  
  1382. Security is optional in the sense that messages may be secure or
  1383. non-secure, even between consecutive message transactions from the same
  1384. client.  It is also optional in that VMTP clients and servers are not
  1385. required to implement secure VMTP (although they are required to respond
  1386. intelligently to attempts to use secure VMTP).  At worst, a Client may
  1387. fail to communicate with a Server if the Server insists on secure
  1388. communication and the Client does not implement security or vice versa.
  1389. However, a failure to communicate in this case is necessary from a
  1390. security standpoint.
  1391.  
  1392.  
  1393. 2.7. Multicast
  1394.  
  1395. The Server entity identifier in a message transaction can identify an
  1396. entity group, in which case the Request is multicast to every Entity in
  1397. this group (on a best-efforts basis).  The Request is retransmitted
  1398. until at least one Response is received (or an error timeout occurs)
  1399. unless it is a datagram Request.  The Client can receive multiple
  1400. Responses to the Request.
  1401.  
  1402. The VMTP service interface does not directly provide reliable multicast
  1403. because it is expensive to provide, rarely needed by applications, and
  1404. can be implemented by applications using the multiple Response feature.
  1405. However, the protocol itself is adequate for reliable multicast using
  1406. positive acknowledgments.  In particular, a sophisticated Client
  1407. implementation could maintain a list of members for each entity group of
  1408. interest and retransmit the Request until acknowledged by all members.
  1409. No modifications are required to the Server implementations.
  1410.  
  1411. VMTP supports a simple form of subgroup addressing.  If the CRE  bit is
  1412. set in a Request, the Request is delivered to the subgroup of entities
  1413. in the Server group that are co-resident with one or more entities in
  1414. the group (or individual entity) identified by the CoresidentEntity
  1415. field of the Request.  This is commonly used to send to the manager
  1416. entity for a particular entity, where Server specifies the group of such
  1417. managers.  Co-resident means "using the same VMTP module", and logically
  1418. on the same network host.  In particular, a Probe request can be sent to
  1419. the particular VMTP management module for an entity by specifying the
  1420. VMTP management group as the Server and the entity in question as the
  1421. CoResidentEntity.
  1422.  
  1423.  
  1424.  
  1425. Cheriton                                                       [page 21]
  1426.  
  1427.  
  1428.  
  1429. RFC 1045                       VMTP                        February 1988 
  1430.  
  1431.  
  1432. As an experimental aspect of the protocol, VMTP supports the Server
  1433. sending a group Response which is sent to the Client as well as members
  1434. of the destination group of Servers to which the original Request was
  1435. sent.  The MDG bit indicates whether the Client is a member of this
  1436. group, allowing the Server module to determine whether separately
  1437. addressed packet groups are required to send the Response to both the
  1438. Client and the Server group.  Normally, a Server accepts a group
  1439. Response only if it has received the Request and not yet responded to
  1440. the Client.  Also, the Server must explicitly indicate it wants to
  1441. accept group Responses.  Logically, this facility is analogous to
  1442. responding to a mail message sent to a distribution list by sending a
  1443. copy of the Response to the distribution list.
  1444.  
  1445.  
  1446. 2.8. Real-time Communication
  1447.  
  1448. VMTP provides three forms of support for real-time communication, in
  1449. addition to its standard facilities, which make it applicable to a wide
  1450. range of real-time applications.  First, a priority is transmitted in
  1451. each Request and Response which governs the priority of its handling.
  1452. The priority levels are intended to correspond roughly to:
  1453.  
  1454.    - urgent/emergency.
  1455.  
  1456.    - important
  1457.  
  1458.    - normal
  1459.  
  1460.    - background.
  1461.  
  1462. with additional gradations for each level.  The interpretation and
  1463. implementation of these priority levels is otherwise host-specific, e.g.
  1464. the assignment to host processing priorities.
  1465.  
  1466. Second, datagram Requests allow the Client to send a datagram to another
  1467. entity or entity group using the VMTP naming, transmission and delivery
  1468. mechanism, but without blocking, retransmissions or acknowledgment.
  1469. (The client can still request acknowledgment using the APG bit although
  1470. the Server does not expect missing portions of a multi-packet datagram
  1471. Request to be retransmitted even if some are not received.)  A datagram
  1472. Request in non-streamed mode supersedes all previous Requests from the
  1473. same Client.  A datagram Request in stream mode is queued (if necessary)
  1474. after previous datagram Requests on the same stream.  (See Section
  1475. 2.11.)
  1476.  
  1477. Finally, VMTP provides several control bit flags to modify the handling
  1478. of Requests and Responses for real-time requirements.  First, the
  1479.  
  1480.  
  1481. Cheriton                                                       [page 22]
  1482.  
  1483.  
  1484.  
  1485. RFC 1045                       VMTP                        February 1988 
  1486.  
  1487.  
  1488. conditional message delivery (CMD) flag causes a Request to be discarded
  1489. if the recipient is not waiting for it when it arrives, similarly for
  1490. the Response.  This option allows a client to send a Request that is
  1491. contingent on the server being able to process it immediately.  The
  1492. header checksum only (HCO) flag indicates that the checksum has been
  1493. calculated only on the VMTP header and not on the data segment.
  1494. Applications such as voice and video can avoid the overhead of
  1495. calculating the checksum on data whose utility is insensitive to typical
  1496. bit errors without losing protection on the header information.
  1497. Finally, the No Retransmission (NRT) flag indicates that the recipient
  1498. of a message should not ask for retransmission if part of the message is
  1499. missing but rather either use what was received or discard it.
  1500.  
  1501. None of these facilities introduce new protocol states.  In fact, the
  1502. total processing overhead in the normal case is a bit flag test for CMD,
  1503. HCO or NRT plus assignment of priority on packet transmission and
  1504. reception.  (In fact, CMD and NRT are not tested in the normal case.)
  1505. The additional code complexity is minimal.  We feel that the overhead
  1506. for providing these real-time facilities is minimal and that these
  1507. facilities are both important and adequate for a wide class of real-time
  1508. applications.
  1509.  
  1510. Several of the normal facilities of VMTP appear useful for real-time
  1511. applications.  First, multicast is useful for distributed, replicated
  1512. (fault-tolerant) real-time applications, allowing efficient state query
  1513. and update for (for example) sensors and control state.  Second, the DGM
  1514. or idempotent flag for Responses has some real-time benefits, namely:  a
  1515. Request is redone to get the latest values when the Response is lost,
  1516. rather than just returning the old values.  The desirability of this
  1517. behavior is illustrated by considering a request for the current time of
  1518. day.  An idempotent handling of this request gives better accuracy in
  1519. returning the current time in the case that a retransmission is
  1520. necessary.  Finally, the request-response semantics (in the absence of
  1521. streaming) of each new Request from a Client terminating the previous
  1522. message transactions from that Client, if any, provides the "most recent
  1523. is most important" handling of processing that most real-time
  1524. applications require.
  1525.  
  1526. In general, a key design goal of VMTP was provide an efficient
  1527. general-purpose transport protocol with the features required for
  1528. real-time communication.  Further experience is required to determine
  1529. whether this goal has been achieved.
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537. Cheriton                                                       [page 23]
  1538.  
  1539.  
  1540.  
  1541. RFC 1045                       VMTP                        February 1988 
  1542.  
  1543.  
  1544. 2.9. Forwarded Message Transactions
  1545.  
  1546. A Server may invoke another Server to handle a Request.  It is fairly
  1547. common for the invocation of the second Server to be the last action
  1548. performed by the first Server as part of handling the Request.  For
  1549. example, the original Server may function primarily to select a process
  1550. to handle the Request.  Also, the Server may simply check the
  1551. authorization on the Request.  Describing this situation in the context
  1552. of RPC, a nested remote procedure call may be the last action in the
  1553. remote procedure and the return parameters are exactly those of the
  1554. nested call.  (This situation is analogous to tail recursion.)
  1555.  
  1556. As an optimization to support this case, VMTP provides a Forward
  1557. operation that allows the server to send the nested Request to the other
  1558. server and have this other server respond directly to the Client.
  1559.  
  1560. If the message transaction being forwarded was not multicast, not secure
  1561. or the two Servers are the same principal and the ForwardCount of the
  1562. Request is less than the maximum forward count of 15, the Forward
  1563. operation is implemented by the Server sending a Request onto the next
  1564. Server with the forwarded Request identified by the same Client and
  1565. Transaction as the original Request and a ForwardCount one greater than
  1566. the Request received from the Client.  In this case, the new Server
  1567. responds directly to the Client.  A forwarded Request is illustrated in
  1568. the following figure.
  1569.  
  1570.  +---------+   Request       +----------+
  1571.  | Client  +---------------->| Server 1 |
  1572.  +---------+                 +----------+
  1573.       ^                        |
  1574.       |                        | forwarded Request
  1575.       |                        V
  1576.       |   Response           +----------+
  1577.       +----------------------| Server 2 |
  1578.                              +----------+
  1579.  
  1580. If the message transaction does not meet the above requirements, the
  1581. Server's VMTP module issues a nested call and simply maps the returned
  1582. Response to a Response to original Request without further Server-level
  1583. processing.  In this case, the only optimization over a user-level
  1584. nested call is one fewer VMTP service operation; the VMTP module handles
  1585. the return to the invoking call directly.  The Server may also use this
  1586. form of forwarding when the Request is part of a stream of message
  1587. transactions.  Otherwise, it must wait until the forwarded message
  1588. transaction completes before proceeding with the subsequent message
  1589. transactions in the stream.
  1590.  
  1591.  
  1592.  
  1593. Cheriton                                                       [page 24]
  1594.  
  1595.  
  1596.  
  1597. RFC 1045                       VMTP                        February 1988 
  1598.  
  1599.  
  1600. Implementation of the user-level Forward operation is optional,
  1601. depending on whether the server modules require this facility.  Handling
  1602. an incoming forwarded Request is a minor modification of handling a
  1603. normal incoming Request.  In particular, it is only necessary to examine
  1604. the ForwardCount field when the Transaction of the Request matches that
  1605. of the last message transaction received from the Client.  Thus, the
  1606. additional complexity in the VMTP module for the required forwarding
  1607. support is minimal; the complexity is concentrated in providing a highly
  1608. optimized user-level Forward primitive, and that is optional.
  1609.  
  1610.  
  1611. 2.10. VMTP Management
  1612.  
  1613. VMTP management includes operations for creating, deleting, modifying
  1614. and querying VMTP entities and entity groups.  VMTP management is
  1615. logically implemented by a VMTP management server module that is invoked
  1616. using a message transaction addressed to the Server, VMTP_MANAGER_GROUP,
  1617. a well-known group entity identifier, in conjunction with Coresident
  1618. Entity mechanism introduced in Section 2.7.  A particular Request may
  1619. address the local module, the module managing a particular entity, the
  1620. set of modules managing those entities contained in a specific group or
  1621. all management modules, as appropriate.
  1622.  
  1623. The VMTP management procedures are specified in Appendix III.
  1624.  
  1625.  
  1626. 2.11. Streamed Message Transactions
  1627.  
  1628. Streamed message transactions refer to two or more message transactions
  1629. initiated by a Client before it receives the response to the first
  1630. message transaction, with each transaction being processed and responded
  1631. to in order but asynchronous relative to the initiation of the
  1632. transactions.  A Client streams messages transactions, and thereby has
  1633. multiple message transactions outstanding, by sending them as part of a
  1634. single run of message transactions.  A run  of message transactions is a
  1635. sequence of message transactions with the same Client and Server and
  1636. consecutive Transaction identifiers, with all but the first and last
  1637. Requests and Responses flagged with the NSR (Not Start Run)  and NER
  1638. (Not End Run)  control bits.  (Conversely, the first Request and
  1639. Response does not have the NSR set and the last Request and Response
  1640. does not have the NER bit set.)  The message transactions in a run use
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649. Cheriton                                                       [page 25]
  1650.  
  1651.  
  1652.  
  1653. RFC 1045                       VMTP                        February 1988 
  1654.  
  1655.  
  1656. consecutive transaction identifiers (except if the STI bit <4> is used
  1657. in one, in which case the transaction identifier for the next message
  1658. transaction is 256 greater, rather than 1).
  1659.  
  1660. The Client retains a record for each outstanding transaction until it
  1661. gets a Response or is timed out in error.  The record provides the
  1662. information required to retransmit the Request.  On retransmission
  1663. timeout, the client retransmits the last Request for which it has not
  1664. received a Response the same as is done with non-streamed communication.
  1665. (I.e. there need be only one timeout for all the outstanding message
  1666. transactions associated with a single client.)
  1667.  
  1668. The consecutive transaction identifiers within a run of message
  1669. transactions are used as sequence numbers for error control.  The Server
  1670. handles each message transaction in the sequence specified by its
  1671. transaction identifier.  When it receives a message transaction that is
  1672. not marked as the beginning of a run, it checks that it previously
  1673. received a message transaction with the predecessor transaction
  1674. identifier, either 1 less than the current one or 256 less if the
  1675. previous one had the STI bit set.  If not, the Server sends a
  1676. NotifyVmtpClient operation to the Client's manager indicating either:
  1677. (1) the first message transaction was not fully received, or else (2) it
  1678. has no record of the last one received.  If the NRT control flag is set,
  1679. it does not await nor expect retransmission but proceeds with handling
  1680. this Request.  This flag is used primarily when datagram Requests are
  1681. used as part of a stream of message transactions.  If NRT was not
  1682. specified, the Client must retransmit from the first message transaction
  1683. not fully received (either at all or in part) before the Server can
  1684. proceed with handling this run of Requests or else restart the run of
  1685. message transactions.
  1686.  
  1687. The Client expects to receive the Responses in a consecutive sequence,
  1688. using the Transaction identifier to detect missing Responses.  Thus, the
  1689. Server must return Responses in sequence except possibly for some gaps,
  1690. as follows.  The Server can specify in the PGcount field in a Response,
  1691. the number of consecutively previous Responses that this Response
  1692.  
  1693.  
  1694.  
  1695.  
  1696. _______________
  1697.  
  1698. <4>   The STI bit is used by the Client to effectively allocate 255
  1699. transaction identifiers for use by the Server in returning a large
  1700. Response or stream of Responses.
  1701.  
  1702.  
  1703. Cheriton                                                       [page 26]
  1704.  
  1705.  
  1706.  
  1707. RFC 1045                       VMTP                        February 1988 
  1708.  
  1709.  
  1710. corresponds to, up to a maximum of 255 previous Responses <5>.  Thus,
  1711. for example, a Response with Transaction identifier 46 and PGcount 3
  1712. represents Responses 43, 44, 45 and 46.  This facility allows the Server
  1713. to eliminate sending Responses to Requests that require no Response,
  1714. effectively batching the Responses into one.  It also allows the Server
  1715. to effectively maintain strictly consecutive sequencing when the Client
  1716. has skipped 256 Transaction identifiers using the STI bit and the Server
  1717. does not have that many Responses to return.
  1718.  
  1719. If the Client receives a Response that is not consecutive, it
  1720. retransmits the Request(s) for which the Response(s) is/are missing
  1721. (unless, of course, the corresponding Requests were sent as datagrams).
  1722. The Client should wait at the end of a run of message transactions for
  1723. the last one to complete.
  1724.  
  1725. When a Server receives a Request with the NSR bit clear and a higher
  1726. transaction identifier than it currently has for the Client, it
  1727. terminates all processing and discards Responses associated with the
  1728. previous Requests.  Thus, a stream of message transactions is
  1729. effectively aborted by starting a new run, even if the Server was in the
  1730. middle of handling the previous run.
  1731.  
  1732. Using a mixture of datagram and normal Requests as part of a stream of
  1733. message transactions, particularly with the use of the NRT bit, can lead
  1734. to complex behavior under packet loss.  It is recommended that a run of
  1735. message transactions be all of one type to avoid problems, i.e. all
  1736. normal or all datagrams.  Finally, when a Server forwards a Request that
  1737. is part of a run, it must suspend further processing of the subsequent
  1738. Requests until the forwarded Request has been handled, to preserve order
  1739. of processing.  The simplest handling of this situation is to use a real
  1740. nested call when forwarding with streamed message transactions.
  1741.  
  1742. Flow control of streamed message transactions relies on rate control at
  1743. the Client plus receipt (or non-receipt) of management notify operations
  1744. indicating the presence of overrunning.  A Client must reduce the number
  1745. of outstanding message transactions at the Server when it receives a
  1746. NotifyVmtpServer operation with the MSGTRANS_OVERFLOW ResponseCode.  The
  1747. transact parameter indicates the last packet group that was accepted.
  1748.  
  1749.  
  1750. _______________
  1751.  
  1752. <5>  PGcount actually corresponds to packet groups which are described
  1753. in Section 2.13.  This (simplified) description is accurate when there
  1754. is one Request or Response per packet group.
  1755.  
  1756.  
  1757. Cheriton                                                       [page 27]
  1758.  
  1759.  
  1760.  
  1761. RFC 1045                       VMTP                        February 1988 
  1762.  
  1763.  
  1764. The implementation of multiple outstanding message transactions requires
  1765. the ability to record, timeout and buffer multiple outstanding message
  1766. transactions at the Client end as well as the Server end.  However, this
  1767. facility is optional for both the Client and the Server.  Client systems
  1768. with heavy-weight processes and high network access cost are most likely
  1769. to benefit from this facility.  Servers that serve a wide variety of
  1770. client machines should implement streaming to accommodate these types of
  1771. clients.
  1772.  
  1773.  
  1774. 2.12. Fault-Tolerant Applications
  1775.  
  1776. One approach to fault-tolerant systems is to maintain a log of all
  1777. messages sent at each node and replay the messages at a node when the
  1778. node fails, after restarting it from the last checkpoint <6>.  As an
  1779. experimental facility, VMTP provides a Receive Sequence Number field in
  1780. the NotifyVmtpClient and NotifyVmtpServer operations as well as the Next
  1781. Receive Sequence (NRS) flag in the Response packet to allow a sender to
  1782. log a receive sequence number with each message sent, allowing the
  1783. packets to be replayed at a recovering node in the same sequence as they
  1784. were originally received, thereby recovering to the same state as
  1785. before.
  1786.  
  1787. Basically, each sending node maintains a receive sequence number for
  1788. each receiving node.  On sending a Request to a node, it presume that
  1789. the receive sequence number is one greater than the one it has recorded
  1790. for that node.  If not, the receiving node sends a notify operation
  1791. indicating the receive sequence number assigned the Request.  The NRS in
  1792. the Response confirms that the Request message was the next receive
  1793. sequence number, so the sender can detect if it failed to receive the
  1794. notify operation in the previous case.  With Responses, the packets are
  1795. ordered by the Transaction identifier except for multicast message
  1796. transactions, in which there may be multiple Responses with the same
  1797. identification.  In this case, NotifyVmtpServer operations are used to
  1798. provide receive sequence numbers.
  1799.  
  1800. This experimental extension of the protocol is focused on support for
  1801. fault-tolerant real-time distributed systems required in various
  1802. critical applications.  It may be removed or extended, depending on
  1803. further investigations.
  1804.  
  1805. _______________
  1806.  
  1807. <6>  The sender-based logging is being investigated by Willy Zwaenepoel
  1808. of Rice University.
  1809.  
  1810.  
  1811. Cheriton                                                       [page 28]
  1812.  
  1813.  
  1814.  
  1815. RFC 1045                       VMTP                        February 1988 
  1816.  
  1817.  
  1818. 2.13. Packet Groups
  1819.  
  1820. A message (whether Request or Response) is sent as one or more packet
  1821. groups.  A packet group is one or more packets, each containing the same
  1822. transaction identification and message control block.  Each packet is
  1823. formatted as below with the message control block logically embedded in
  1824. the VMTP header.
  1825.  
  1826.  +------------------------------------++---------------------+
  1827.  |            VMTP Header             ||                     |
  1828.  +------------+-----------------------||   segment data      |
  1829.  |VMTP Control| Message Control Block ||                     |
  1830.  +------------+-----------------------++---------------------+
  1831.  
  1832. The some fields of the VMTP control portion of the packet and data
  1833. segment portion can differ between packets within the same packet group.
  1834.  
  1835. The segment data portion of a packet group represents up to 16
  1836. kilooctets of the segment specified in the message control block.  The
  1837. portion contained in each packet is indicated by the PacketDelivery
  1838. field contained in the VMTP header.  The PacketDelivery field as a bit
  1839. mask has a similar interpretation to the MsgDelivery field in that each
  1840. bit corresponds to a segment data block of 512 octets.  The
  1841. PacketDelivery field limits a packet group to 16 kilooctets and a
  1842. maximum of 32 VMTP packets (with a minimum of 1 packet).  Data can be
  1843. sent in fewer packets by sending multiple data blocks per packet.  We
  1844. require that the underlying datagram service support delivery of (at
  1845. minimum) the basic 580 octet VMTP packet <7>.  To illustrate the use of
  1846. the PacketDelivery field, consider for example the Ethernet which has a
  1847. MTU of 1536 octets.  so one would send 2 512-octet segment data blocks
  1848. per packet.  (In fact, if a third block is last in the segment and less
  1849. than 512 octets and fits in the packet without making it too big, an
  1850. Ethernet packet could contain three data blocks.  Thus, an Ethernet
  1851. packet group for a segment of size 0x1D00 octets (14.5 blocks) and
  1852. MsgDelivery 0x000074FF consists of 6 packets indicated as follows <8>.
  1853.  
  1854. _______________
  1855.  
  1856. <7>  Note that with a 20 octet IP header, a VMTP packet is 600
  1857. octets.  We propose the convention that any host implementing VMTP
  1858. implicitly agrees to accept IP/VMTP packets of at least 600 octets.
  1859.  
  1860. <8>  We use the C notation 0xHHHH to represent a hexadecimal number.
  1861.  
  1862.  
  1863. Cheriton                                                       [page 29]
  1864.  
  1865.  
  1866.  
  1867. RFC 1045                       VMTP                        February 1988 
  1868.  
  1869.  
  1870.  Packet
  1871.  Delivery  1 1  1 1  1 1  1 1  0 0  1 0  1 0  1 0  0 0 0 0 0 . . .
  1872.            0000 0400 0800 0C00 1000 1400 1800 1C00
  1873.           +----+----+----+----+----+----+----+-+
  1874.  Segment  |....|....|....|....|....|....|....|.|
  1875.           +----+----+----+----+----+----+----+-+
  1876.           :    :    :    :    :    :  : /  /   :
  1877.           v    v    v    v    v    v  v   /|   v
  1878.           +----+----+----+----+    +----+  +---+
  1879.  Packets  |  1 |  2 |  3 |  4 |    |  5 |  | 6 |
  1880.           +----+----+----+----+    +----+  +---+
  1881.  
  1882. Each '.' is 256 octets of data.  The PacketDelivery masks for the 6
  1883. packets are: 0x00000003, 0x0000000C, 0x00000030, 0x000000C0, 0x00001400
  1884. and 0x00006000, indicating the segment blocks contained in each of the
  1885. packets.  (Note that the delivery bits are in little endian order.)
  1886.  
  1887. A packet group is sent as a single "blast" of packets with no explicit
  1888. flow control.  However, the sender should estimate and transmit at a
  1889. rate of packet transmission to avoid congesting the network or
  1890. overwhelming the receiver, as described in Section 2.5.6.  Packets in a
  1891. packet group can be sent in any order with no change in semantics.
  1892.  
  1893. When the first packet of a packet group is received (assuming the Server
  1894. does not decide to discard the packet group), the Server saves a copy of
  1895. the VMTP packet header, indicates it is currently receiving a packet
  1896. group, initializes a "current delivery mask" (indicating the data in the
  1897. segment received so far) to 0, accepts this packet (updating the current
  1898. delivery mask) and sets the timer for the packet group.  Subsequent
  1899. packets in the packet group update the current delivery mask.
  1900.  
  1901. Reception of a packet group is terminated when either the current
  1902. delivery mask indicates that all the packets in the packet group have
  1903. been received or the packet group reception timer expires (set to TC3 or
  1904. TS1).  If the packet group reception timer expires, if the NRT bit is
  1905. set in the Control flags then the packet group is discarded if not
  1906. complete unless MDM is set.  In this case, the MsgDelivery field in the
  1907. message control block is set to indicate the segment data blocks
  1908. actually received and the message control block and segment data
  1909. received is delivered to application level.
  1910.  
  1911. If NRT is not set and not all data blocks have been received, a
  1912. NotifyVmtpClient (if a Request) or NotifyVmtpServer (if a Response) is
  1913. sent back with a PacketDelivery field indicating the blocks received.
  1914. The source of the packet group is then expected to retransmit the
  1915. missing blocks.  If not all blocks of a Request are received after
  1916. RequestAckRetries(Client) retransmissions, the Request is discarded and
  1917.  
  1918.  
  1919. Cheriton                                                       [page 30]
  1920.  
  1921.  
  1922.  
  1923. RFC 1045                       VMTP                        February 1988 
  1924.  
  1925.  
  1926. a NotifyVmtpClient operation with an error response code is sent to the
  1927. client's manager unless MDM is set.  With a Response, there are
  1928. ResponseAckRetries(Server) retransmissions and then, if MDM is not set,
  1929. the requesting entity is returned the message control block with an
  1930. indication of the amount of segment data received extending contiguously
  1931. from the start of the segment.  E.g. if the sender sent 6 512-octet
  1932. blocks and only the first two and the last two arrived, the receiver
  1933. would be told that 1024 octets were received.  The ResponseCode field is
  1934. set to BAD_REPLY_SEGMENT.  (Note that VMTP is only able to indicate the
  1935. specific segment blocks received if MDM is set.)
  1936.  
  1937. The parameters RequestAckRetries(Client) and ResponseAckRetries(Server)
  1938. could be set on a per-client and per-server basis in a sophisticated
  1939. implementation based on knowledge of packet loss.
  1940.  
  1941. If the APG flag is set, a NotifyVmtpClient or NotifyVmtpServer
  1942. operation is sent back at the end of the packet group reception,
  1943. depending on whether it is a Request or a Response.
  1944.  
  1945. At minimum, a Server should check that each packet in the packet group
  1946. contains the same Client, Server, Transaction identifier and SegmentSize
  1947. fields.  It is a protocol error for any field other than the Checksum,
  1948. packet group control flags, Length and PacketDelivery in the VMTP header
  1949. to differ between any two packets in one packet group.  A packet group
  1950. containing a protocol error of this nature should be discarded.
  1951.  
  1952. Notify operations should be sent (or invoked) in the manager whenever
  1953. there is a problem with a unicast packet.  i.e. negative acknowledgments
  1954. are always sent in this case.  In the case of problems with multicast
  1955. packets, the default is to send nothing in response to an error
  1956. condition unless there is some clear reason why no other node can
  1957. respond positively.  For example, the packet might be a Probe for an
  1958. entity that is known to have been recently existing on the receiving
  1959. host but now invalid and could not have migrated.  In this case, the
  1960. receiving host responds to the Probe indicating the entity is
  1961. nonexistent, knowing that no other host can respond to the Probe.  For
  1962. packets and packet groups that are received and processed without
  1963. problems, a Notify operation is invoked only if the APG bit is set.
  1964.  
  1965.  
  1966. 2.14. Runs of Packet Groups
  1967.  
  1968. A run of packet groups is a sequence of packet groups, all Request
  1969. packets or all Response packets, with the same Client and consecutive
  1970. transaction identifiers, all but the first and last packets flagged with
  1971. the NSR (Not Start Run) and NER (Not End Run) control bits.  When each
  1972. packet group in the run corresponds to a single Request or Response, it
  1973.  
  1974.  
  1975. Cheriton                                                       [page 31]
  1976.  
  1977.  
  1978.  
  1979. RFC 1045                       VMTP                        February 1988 
  1980.  
  1981.  
  1982. is identical to a run of message transactions. (See Section 2.11)
  1983. However, a Request message or a Response message may consists of up to
  1984. 256 packet groups within a run, for a maximum of 4 megaoctets of segment
  1985. data.  A message that is continued in the next packet group in the run
  1986. is flagged in the current packet group by the CMG flag.  Otherwise, the
  1987. next packet group in the run (if any) is treated as a separate Request
  1988. or Response.
  1989.  
  1990. Normally, each Request and Response message is sent as a single packet
  1991. group and each run consists of a single packet group.  In this case
  1992. neither NSR or NER are set.  For multi-packet group messages, the
  1993. PacketDelivery mask in the i-th packet group of a message corresponds to
  1994. the portion of the segment offset by i-1 times 16 kilooctets,
  1995. designating the the first packet group to have i = 1.
  1996.  
  1997.  
  1998. 2.15. Byte Order
  1999.  
  2000. For purposes of transmission and reception, the MCB is treated as
  2001. consisting of 8 32-bit fields and the segment is a sequence of bytes.
  2002. VMTP transmits the MCB in big-endian order, performing byte-swapping, if
  2003. necessary, before transmission.  A little-endian host must byte-swap the
  2004. MCB on reception.  (The data segment is transmitted as a sequence of
  2005. bytes with no reordering.)  The byte order of the sender of a message is
  2006. indicated by the LEE  bit in the entity identifier for the sender, the
  2007. Client field if a Request and the Server field if a Response.  The
  2008. sender and receiver of a message are required to agree in some higher
  2009. level protocol (such as an RPC presentation protocol) on who does
  2010. further swapping of the MCB and data segment if required by the types of
  2011. the data actually being transmitted.  For example, the segment data may
  2012. contain a record with 8-bit, 16-bit and 32-bit fields, so additional
  2013. transformation is required to move the segment from a host of one byte
  2014. order to another.
  2015.  
  2016. VMTP to date has used a higher-level presentation protocol in which
  2017. segment data is sent in the native order of the sending host and
  2018. byte-swapped as necessary by the receiving host.  This approach
  2019. minimizes the byte-swapping overhead between machines of common byte
  2020. order (including when the communication is transparently local to one
  2021. host), avoids a strong bias in the protocol to one byte-order, and
  2022. allows for the sending entity to be sending to a group of hosts with
  2023. different byte orders.  (Note that the byte-swap overhead for the MCB is
  2024. minimal.)  The presentation-level overhead is minimal because most
  2025. common operations, such as file access operations, have parameters that
  2026. fit the MCB and data segment data types exactly.
  2027.  
  2028.  
  2029.  
  2030.  
  2031. Cheriton                                                       [page 32]
  2032.  
  2033.  
  2034.  
  2035. RFC 1045                       VMTP                        February 1988 
  2036.  
  2037.  
  2038. 2.16. Minimal VMTP Implementation
  2039.  
  2040. A minimal VMTP client needs to be able to send a Request packet group
  2041. and receive a Response packet group as well as accept and respond to
  2042. Requests sent to its management module, including Probe and NotifyClient
  2043. operations.  It may also require the ability to invoke Probe and Notify
  2044. operations to locate a Server and acknowledge responses.  (the latter
  2045. only if it is involved in transactions that are not idempotent or
  2046. datagram message transactions.  However, a simple sensor, for example,
  2047. can transmit VMTP datagram Requests indicating its current state with
  2048. even less mechanism.)  The minimal client thus requires very little code
  2049. and is suitable as a basis for (e.g.) a network boot loader.
  2050.  
  2051. A minimal VMTP server implements idempotent, non-encrypted message
  2052. transactions, possibly with no segment data support.  It should use an
  2053. entity state record for each Request but need only retain it while
  2054. processing the Request.  Without segment data larger than a packet,
  2055. there is no need for any timers, buffering (outside of immediate request
  2056. processing) or queuing.  In particular, it needs only as many records as
  2057. message transactions it handles simultaneously (e.g. 1).  The entity
  2058. state record is required to recognize and respond to Request
  2059. retransmissions during request processing.
  2060.  
  2061. The minimal server need only receive Requests and and be able to send
  2062. Response packets.  It need have only a minimal management module
  2063. supporting Probe operations.  (Support for the NotifyVmtpClient
  2064. operation is only required if it does not respond immediately to a
  2065. Request.)  Thus the VMTP support for say a time server, sensor, or
  2066. actuator can be extremely simple.  Note that the server need never issue
  2067. a Probe operation if it uses the host address of the Request for the
  2068. Response and does not require the Client information returned by the
  2069. Probe operation.  The minimal server should also support reception of
  2070. forwarded Requests.
  2071.  
  2072.  
  2073. 2.17. Message vs. Procedural Request Handling
  2074.  
  2075. A request-response protocol can be used to implement two forms of
  2076. semantics on reception.  With procedural handling of a Request, a
  2077. Request is handled by a process associated with the Server that
  2078. effectively takes on the identity of the calling process, treating the
  2079. Request message as invoking a procedure, and relinquishing its
  2080. association to the calling process on return.  VMTP supports multiple
  2081. nested calls spanning multiple machines.  In this case, the distributed
  2082. call stack that results is associated with a single process from the
  2083. standpoint of authentication and resource management, using the
  2084. ProcessId field supported by VMTP.  The entity identifiers effectively
  2085.  
  2086.  
  2087. Cheriton                                                       [page 33]
  2088.  
  2089.  
  2090.  
  2091. RFC 1045                       VMTP                        February 1988 
  2092.  
  2093.  
  2094. link these call frames together.  That is, the Client field in a Request
  2095. is effectively the return link to the previous call frame.
  2096.  
  2097. With message handling of a Request, a Request message is queued for a
  2098. server process.  The server process dequeues, reads, processes and
  2099. responds to the Request message, executing as a separate process.
  2100. Subsequent Requests to the same server are queued until the server asks
  2101. to receive the next Request.
  2102.  
  2103. Procedural semantics have the advantage of allowing each Request (up to
  2104. the resource limits of the Server) to execute concurrently at the
  2105. Server, with Request-specific synchronization.  Message semantics have
  2106. the advantage that Requests are serialized at the Server and that the
  2107. request processing logically executes with the priority, protection and
  2108. independent execution of a separate process.  Note that procedural and
  2109. message handling of a request appear no differently to the client
  2110. invoking the message transaction, except possibly for differences in
  2111. performance.
  2112.  
  2113. We view the two Request handling approaches as appropriate under
  2114. different circumstances.  VMTP supports both models.
  2115.  
  2116.  
  2117. 2.18. Bibliography
  2118.  
  2119. The basic protocol is similar to that used in the original form of the V
  2120. kernel [3, 4] as well as the transport protocol of Birrell and
  2121. Nelson's [2] remote procedure call mechanism.  An earlier version of the
  2122. protocol was described in SIGCOMM'86 [6].  The rate-based flow control
  2123. is similar to the techniques of Netblt [9].  The support for idempotency
  2124. draws, in part, on the favorable experience with idempotency in the V
  2125. distributed system.  Its use was originally inspired by the Woodstock
  2126. File Server [11].  The multicast support draws on the multicast
  2127. facilities in V [5] and is designed to work with, and is now implemented
  2128. using, the multicast extensions to the Internet [8] described in RFC 966
  2129. and 988.  The secure version of the protocol is similar to that
  2130. described by Birrell [1] for secure RPC.  The use of runs of packet
  2131. groups is similar to Fletcher and Watson's delta-T protocol [10].  The
  2132. use of "management" operations implemented using VMTP in place of
  2133. specialized packet types is viewed as part of a general strategy of
  2134. using recursion to simplify protocol architectures [7].
  2135.  
  2136. Finally, this protocol was designed, in part, to respond to the
  2137. requirements identified by Braden in RFC 955.  We believe that VMTP
  2138. satisfies the requirements stated in RFC 955.
  2139.  
  2140.  
  2141.  
  2142.  
  2143. Cheriton                                                       [page 34]
  2144.  
  2145.  
  2146.  
  2147. RFC 1045                       VMTP                        February 1988 
  2148.  
  2149.  
  2150.  
  2151. [1]   A.D. Birrell, "Secure Communication using Remote Procedure
  2152.       Calls", ACM. Trans. on Computer Systems 3(1), February, 1985.
  2153.  
  2154.  
  2155. [2]   A. Birrell and B. Nelson, "Implementing Remote Procedure Calls",
  2156.       ACM Trans. on Computer Systems 2(1), February, 1984.
  2157.  
  2158.  
  2159. [3]   D.R. Cheriton and W. Zwaenepoel, "The Distributed V Kernel and its
  2160.       Performance for Diskless Workstations", In Proceedings of the 9th
  2161.       Symposium on Operating System Principles,  ACM, 1983.
  2162.  
  2163.  
  2164. [4]   D.R. Cheriton, "The V Kernel: A Software Base for Distributed
  2165.       Systems", IEEE Software 1(2), April, 1984.
  2166.  
  2167.  
  2168. [5]   D.R. Cheriton and W. Zwaenepoel, "Distributed Process Groups in
  2169.       the V Kernel", ACM Trans. on Computer Systems 3(2), May, 1985.
  2170.  
  2171.  
  2172. [6]   D.R. Cheriton, "VMTP: A Transport Protocol for the Next
  2173.       Generation of Communication Systems", In Proceedings of
  2174.       SIGCOMM'86, ACM, Aug 5-7, 1986.
  2175.  
  2176.  
  2177. [7]   D.R. Cheriton, "Exploiting Recursion to Simplify an RPC 
  2178.       Communication Architecture", in preparation, 1988.
  2179.  
  2180.  
  2181. [8]   D.R. Cheriton and S.E. Deering, "Host Groups: A Multicast 
  2182.       Extension for Datagram Internetworks", In 9th Data Communication 
  2183.       Symposium, IEEE Computer Society and ACM SIGCOMM, September, 1985.
  2184.  
  2185.  
  2186. [9]   D.D. Clark and M. Lambert and L. Zhang, "NETBLT: A Bulk Data 
  2187.       Transfer Protocol", Technical Report RFC 969, Defense Advanced 
  2188.       Research Projects Agency, 1985.
  2189.  
  2190.  
  2191. [10]  J.G. Fletcher and R.W. Watson, "Mechanism for a Reliable Timer-
  2192.       based Protocol", Computer Networks 2:271-290, 1978.
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203. Cheriton                                                       [page 35]
  2204.  
  2205.  
  2206.  
  2207. RFC 1045                       VMTP                        February 1988 
  2208.  
  2209.  
  2210.  
  2211.  
  2212. [11]  D. Swinehart and G. McDaniel and D. Boggs, "WFS: A Simple File 
  2213.       System for a Distributed Environment", In Proc. 7th Symp. 
  2214.       Operating Systems Principles, 1979.
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236.  
  2237.  
  2238.  
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250.  
  2251.  
  2252.  
  2253.  
  2254.  
  2255.  
  2256.  
  2257.  
  2258.  
  2259.  
  2260. Cheriton                                                       [page 36]
  2261.  
  2262.  
  2263.  
  2264. RFC 1045                       VMTP                        February 1988 
  2265.  
  2266.  
  2267. 3. VMTP Packet Formats
  2268.  
  2269. VMTP uses 2 basic packet formats corresponding to Request packets and
  2270. Response packets.  These packet formats are identical in most of the
  2271. fields to simplify the implementation.
  2272.  
  2273. We first describe the entity identifier format and the packet fields
  2274. that are used in general, followed by a detailed description of each of
  2275. the packet formats.  These fields are described below in detail.  The
  2276. individual packet formats are described in the following subsections.
  2277. The reader and VMTP implementor may wish to refer to Chapters 4 and 5
  2278. for a description of VMTP event handling and only refer to this detailed
  2279. description as needed.
  2280.  
  2281.  
  2282. 3.1. Entity Identifier Format
  2283.  
  2284. The 64-bit non-group entity identifiers have the following substructure.
  2285.  
  2286.   0                   1                   2                   3
  2287.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2288.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2289.  |R| |L|R|
  2290.  |A|0|E|E|      Domain-specific structure
  2291.  |E| |E|S|
  2292.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2293.                 Domain-specific structure                        |
  2294.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2295.  
  2296. The field meanings are as follows:
  2297.  
  2298. RAE             Remote Alias Entity - the entity identifier identifies
  2299.                 an entity that is acting as an alias for some entity
  2300.                 outside this entity domain.  This bit is used by
  2301.                 higher-level protocols.  For instance, servers may take
  2302.                 extra security and protection measures with aliases.
  2303.  
  2304. GRP             Group - 0, for non-group entity identifiers.
  2305.  
  2306. LEE             Little-Endian Entity - the entity transmits data in
  2307.                 little-endian (VAX) order.
  2308.  
  2309. RES              Reserved - must be 0.
  2310.  
  2311. The 64-bit entity group identifiers have the following substructure.
  2312.  
  2313.  
  2314.  
  2315.  
  2316. Cheriton                                                       [page 37]
  2317.  
  2318.  
  2319.  
  2320. RFC 1045                       VMTP                        February 1988 
  2321.  
  2322.  
  2323.   0                   1                   2                   3
  2324.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2325.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2326.  |R| |U|R|
  2327.  |A|1|G|E|      Domain-specific structure
  2328.  |E| |P|S|
  2329.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2330.                 Domain-specific structure                        |
  2331.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2332.  
  2333. The field meanings are as follows:
  2334.  
  2335. RAE             Remote Alias Entity - same as for non-group entity
  2336.                 identifier.
  2337.  
  2338. GRP             Group - 1, for entity group identifiers.
  2339.  
  2340. UGP             Unrestricted Group - no restrictions are placed on
  2341.                 joining this group.  I.e. any entity can join limited
  2342.                 only by implementation resources.
  2343.  
  2344. RES              Reserved - must be 0.
  2345.  
  2346. The all-zero entity identifier is reserved and guaranteed to be
  2347. unallocated in all domains.  In addition, a domain may reserve part of
  2348. the entity identifier space for statically allocated identifiers.
  2349. However, this is domain-specific.
  2350.  
  2351. Description of currently defined entity identifier domains is provided
  2352. in Appendix IV.
  2353.  
  2354.  
  2355. 3.2. Packet Fields
  2356.  
  2357. Client          64-bit identifier for the client entity associated with
  2358.                 this packet.  The structure, allocation and binding of
  2359.                 this identifier is specific to the specified Domain.  An
  2360.                 entity identifier always includes 4 types bits as
  2361.                 specified in Section 3.1.
  2362.  
  2363. Version         The 3-bit identifier specifying the version of the
  2364.                 protocol.  Current version is version 0.
  2365.  
  2366. Domain          The 13-bit identifier specifying the naming and
  2367.                 administration domain for the client and server named in
  2368.                 the packet.
  2369.  
  2370.  
  2371.  
  2372. Cheriton                                                       [page 38]
  2373.  
  2374.  
  2375.  
  2376. RFC 1045                       VMTP                        February 1988 
  2377.  
  2378.  
  2379. Packet Flags: 3 bits. (The normal case has none of the flags set.)
  2380.  
  2381.   HCO           Header checksum only - checksum has only been calculated
  2382.                 on the header.  This is used in some real-time
  2383.                 applications where the strict correctness of the data is
  2384.                 not needed.
  2385.  
  2386.   EPG           Encrypted packet group - part of a secure message
  2387.                 transaction.
  2388.  
  2389.   MPG           Multicast packet group - packet was multicast on
  2390.                 transmission.
  2391.  
  2392. Length          A 13-bit field that specifies the number of 32-bit words
  2393.                 in the segment data portion of the packet (if any),
  2394.                 excluding the checksum field.  (Every VMTP packet is
  2395.                 required to be a multiple of 64 bits, possibly by
  2396.                 padding out the segment data.)  The minimum legal Length
  2397.                 is 0, the maximum length is 4096 and it must be an even
  2398.                 number.
  2399.  
  2400. Control Flags: 9 bits. (The normal case has none of the flags set.)
  2401.  
  2402.   NRS           Next Receive Sequence - the associated Request message
  2403.                 (in a Response) or previous Response (if a Request) was
  2404.                 received consecutive with the last Request from this
  2405.                 entity.  That is, there was no interfering messages
  2406.                 received.
  2407.  
  2408.   APG           Acknowledge Packet Group - Acknowledge packet group on
  2409.                 receipt.  If a Request, send back a Request to the
  2410.                 client's manager providing an update on the state of the
  2411.                 transaction as soon as the request packet group is
  2412.                 received, independent of the response being available.
  2413.                 If a Response, send an update to the server's manager as
  2414.                 soon as possible after response packet group is received
  2415.                 providing an update on the state of the transaction at
  2416.                 the client
  2417.  
  2418.   NSR           Not Start Run - 1 if this packet is not part of the
  2419.                 first packet group of a run of packet groups.
  2420.  
  2421.   NER           Not End Run - 1 if this packet is not part of the last
  2422.                 packet group of a run of packet groups.
  2423.  
  2424.   NRT           No Retransmission - do not ask for retransmissions of
  2425.                 this packet group if not all received within timeout
  2426.  
  2427.  
  2428. Cheriton                                                       [page 39]
  2429.  
  2430.  
  2431.  
  2432. RFC 1045                       VMTP                        February 1988 
  2433.  
  2434.  
  2435.                 period, just deliver or discard.
  2436.  
  2437.   MDG           Member of Destination Group - this packet is sent to a
  2438.                 group and the client is a member of this group.
  2439.  
  2440.   CMG           Continued Message - the message (Request or Response) is
  2441.                 continued in the next packet group.  The next packet
  2442.                 group has to be part of the same run of packet groups.
  2443.  
  2444.   STI           Skip Transaction Identifiers - the next transaction
  2445.                 identifier that the Client plans to use is the current
  2446.                 transaction plus 256, if part of the same run and at
  2447.                 least this big if not.  In a Request, this authorizes
  2448.                 the Server to send back up to 256 packet groups
  2449.                 containing the Response.
  2450.  
  2451.   DRT           Delay Response Transmission - set by request sender if
  2452.                 multiple responses are expected (as indicated by the MRD
  2453.                 flag in the RequestCode) and it may be overrun by
  2454.                 multiple responses.  The responder(s) should then
  2455.                 introduce a short random delay in sending the Response
  2456.                 to minimize the danger of overrunning the Client.  This
  2457.                 is normally only used for responding to multicast
  2458.                 Requests where the Client may be receiving a large
  2459.                 number of Responses, as indicated by the MRD flag in the
  2460.                 Request flags.  Otherwise, the Response is sent
  2461.                 immediately.
  2462.  
  2463. RetransmitCount:
  2464.                 3 bits - the ordinal number of transmissions of this
  2465.                 packet group prior to this one, modulo 8.  This field is
  2466.                 used in estimation of roundtrip times.  This count may
  2467.                 wrap around during a message transaction.  However, it
  2468.                 should be sufficient to match acknowledgments and
  2469.                 responses with a particular transmission.
  2470.  
  2471. ForwardCount:   4 bits indicating the number of times this Request has
  2472.                 been forwarded.  The original Request is always sent
  2473.                 with a ForwardCount of 0.
  2474.  
  2475. Interpacket Gap: 8 bits.  
  2476.                 Indicates the recommended time to use between subsequent
  2477.                 packet transmissions within a multi-packet packet group
  2478.                 transmission.  The Interpacket Gap time is in 1/32nd of
  2479.                 a network packet transmission time for a packet of size
  2480.                 MTU for the node.  (Thus, the maximum gap time is 8
  2481.                 packet times.)
  2482.  
  2483.  
  2484. Cheriton                                                       [page 40]
  2485.  
  2486.  
  2487.  
  2488. RFC 1045                       VMTP                        February 1988 
  2489.  
  2490.  
  2491. PGcount: 8 bits 
  2492.                 The number of packet groups that this packet group
  2493.                 represents in addition to that specified by the
  2494.                 Transaction field.  This is used in acknowledging
  2495.                 multiple packet groups in streamed communication.
  2496.  
  2497. Priority        4-bit identifier for priority for the processing of this
  2498.                 request both on transmission and reception.  The
  2499.                 interpretation is:
  2500.  
  2501.                 1100            urgent/emergency
  2502.  
  2503.                 1000            important
  2504.  
  2505.                 0000            normal
  2506.  
  2507.                 0100            background
  2508.  
  2509.                 Viewing the higher-order bit as a sign bit (with 1
  2510.                 meaning negative), low values are high priority and high
  2511.                 values are low priority.  The low-order 2 bits indicate
  2512.                 additional (lower) gradations for each level.
  2513.  
  2514. Function Code: 1 bit - types of VMTP packets.  If the low-order bit of
  2515.                 the function code is 0, the packet is sent to the
  2516.                 Server, else it is sent to the Client.
  2517.  
  2518.                 0               Request
  2519.  
  2520.                 1               Response
  2521.  
  2522. Transaction: 32 bits:  
  2523.                 Identifier for this message transaction.
  2524.  
  2525. PacketDelivery: 32 bits:  
  2526.                 Delivery indicates the segment blocks contained in this
  2527.                 packet.  Each bit corresponds to one 512-octet block of
  2528.                 segment data.  A 1 bit in the i-th bit position
  2529.                 (counting the LSB as 0) indicates the presence of the
  2530.                 i-th segment block.
  2531.  
  2532. Server: 64 bits 
  2533.                 Entity identifier for the server or server group
  2534.                 associated with this transaction.  This is the receiver
  2535.                 when a Request packet and the sender when a Response
  2536.                 packet.
  2537.  
  2538.  
  2539.  
  2540. Cheriton                                                       [page 41]
  2541.  
  2542.  
  2543.  
  2544. RFC 1045                       VMTP                        February 1988 
  2545.  
  2546.  
  2547. Code: 32 bits   The Request Code and Response Code, set either at the
  2548.                 user level or VMTP level depending on use and packet
  2549.                 type.  Both the Request and Response codes include 8
  2550.                 high-order bits from the following set of control bits:
  2551.  
  2552.   CMD           Conditional Message Delivery -  only deliver the request
  2553.                 or response if the receiving entity is waiting for it at
  2554.                 the time of delivery, otherwise drop the message.
  2555.  
  2556.   DGM           DataGram Message - indicates that the message is being
  2557.                 sent as a datagram.  If a Request message, do not wait
  2558.                 for reply, or retransmit.  If a Response message, treat
  2559.                 this message transaction as idempotent.
  2560.  
  2561.   MDM           Message Delivery Mask - indicates that the MsgDelivery
  2562.                 field is being used.  Otherwise, the MsgDelivery field
  2563.                 is available for general use.
  2564.  
  2565.   SDA           Segment Data Appended - segment data is appended to the
  2566.                 message control block, with the total size of the
  2567.                 segment specified by the SegmentSize field.  Otherwise,
  2568.                 the segment data is null and the SegmentSize field is
  2569.                 not used by VMTP and available for user- or RPC-level
  2570.                 uses.
  2571.  
  2572.   CRE           CoResident Entity - indicates that the CoResidentEntity
  2573.                 field in the message should be interpreted by VMTP.
  2574.                 Otherwise, this field is available for additional user
  2575.                 data.
  2576.  
  2577.   MRD           Multiple Responses Desired - multiple Responses are
  2578.                 desired to to this Request if it is multicast.
  2579.                 Otherwise, the VMTP module can discard subsequent
  2580.                 Responses after the first Response.
  2581.  
  2582.   PIC           Public Interface Code - Values for Code with this bit
  2583.                 set are reserved for definition by the VMTP
  2584.                 specification and other standard protocols defined on
  2585.                 top of VMTP.
  2586.  
  2587.   RES           Reserved for future use. Must be 0.
  2588.  
  2589. CoResidentEntity
  2590.                 64-bit Identifier for an entity or group of entities
  2591.                 with which the Server entity or entities must be
  2592.                 co-resident, i.e. route only to entities (identified by
  2593.                 Server) on the same host(s) as that specified by
  2594.  
  2595.  
  2596. Cheriton                                                       [page 42]
  2597.  
  2598.  
  2599.  
  2600. RFC 1045                       VMTP                        February 1988 
  2601.  
  2602.  
  2603.                 CoResidentEntity, Only meaningful if CRE is set in the
  2604.                 Code field.
  2605.  
  2606. User Data       12 octets Space in the header for the VMTP user to
  2607.                 specify user-specific control and data.
  2608.  
  2609. MsgDelivery: 32 bits 
  2610.                 The segment blocks being transmitted (in total) in this
  2611.                 packet group following the conventions for the
  2612.                 PacketDelivery field.  This field is ignored by the
  2613.                 protocol and treated as an additional user data field if
  2614.                 MDM is 0.  On transmission, the user level sets the
  2615.                 MsgDelivery to indicate those portions of the segment to
  2616.                 be transmitted.  On receipt, the MsgDelivery field is
  2617.                 modified by the VMTP module to indicate the segment data
  2618.                 blocks that were actually received before the message
  2619.                 control block is passed to the user or RPC level.  In
  2620.                 particular, the kernel does not discard the packet group
  2621.                 if segment data blocks are missing.  A Server or Client
  2622.                 entity receiving a message with a MsgDelivery in use
  2623.                 must check the field to ensure adequate delivery and
  2624.                 retry the operation if necessary.
  2625.  
  2626. SegmentSize: 32 bits 
  2627.                 Size of segment in octets, up to a maximum of 16
  2628.                 kilooctets without streaming and 4 megaoctets with
  2629.                 streaming, if SDA is set.  Otherwise, this field is
  2630.                 ignored by the protocol and treated as an additional
  2631.                 user data field.
  2632.  
  2633. Segment Data: 0-16 kilooctets 
  2634.                 0 octets if SDA is 0, else the portion of the segment
  2635.                 corresponding to the Delivery Mask, limited by the
  2636.                 SegmentSize and the MTU, padded out to a multiple of 64
  2637.                 bits.
  2638.  
  2639. Checksum: 32 bits.  
  2640.                 The 32-bit checksum for the header and segment data.
  2641.  
  2642.  
  2643. The VMTP checksum algorithm <9> develops a 32-bit checksum by computing
  2644.  
  2645. _______________
  2646.  
  2647. <9>  This algorithm and description are largely due to Steve Deering of
  2648. Stanford University.
  2649.  
  2650.  
  2651. Cheriton                                                       [page 43]
  2652.  
  2653.  
  2654.  
  2655. RFC 1045                       VMTP                        February 1988 
  2656.  
  2657.  
  2658. two 16-bit, ones-complement sums (like IP), each covering different
  2659. parts of the packet.  The packet is divided into clusters of 16 16-bit
  2660. words.  The first, third, fifth,... clusters are added to the first sum,
  2661. and the second, fourth, sixth,... clusters are added to the second sum.
  2662. Addition stops at the end of the packet; there is no need to pad out to
  2663. a cluster boundary (although it is necessary that the packet be an
  2664. integral multiple of 64 bits; padding octets may have any value and are
  2665. included in the checksum and in the transmitted packet).  If either of
  2666. the resulting sums is zero, it is changed to 0xFFFF.  The two sums are
  2667. appended to the transmitted packet, with the first sum being transmitted
  2668. first.  Four bytes of zero in place of the checksum may be used to
  2669. indicate that no checksum was computed.
  2670.  
  2671. The 16-bit, ones-complement addition in this algorithm is the same as
  2672. used in IP and, therefore, subject to the same optimizations.  In
  2673. particular, the words may be added up 32-bits at a time as long as the
  2674. carry-out of each addition is added to the sum on the following
  2675. addition, using an "add-with-carry" type of instruction.  (64-bit or
  2676. 128-bit additions would also work on machines that have registers that
  2677. big.)
  2678.  
  2679. A particular weakness of this algorithm (shared by IP) is that it does
  2680. not detect the erroneous swapping of 16-bit words, which may easily
  2681. occur due to software errors.  A future version of VMTP is expected to
  2682. include a more secure algorithm, but such an algorithm appears to
  2683. require hardware support for efficient execution.
  2684.  
  2685. Not all of these fields are used in every packet.  The specific packet
  2686. formats are described below.  If a field is not mentioned in the
  2687. description of a packet type, its use is assumed to be clear from the
  2688. above description.
  2689.  
  2690.  
  2691.  
  2692.  
  2693.  
  2694.  
  2695.  
  2696.  
  2697.  
  2698.  
  2699.  
  2700.  
  2701.  
  2702.  
  2703.  
  2704.  
  2705.  
  2706.  
  2707. Cheriton                                                       [page 44]
  2708.  
  2709.  
  2710.  
  2711. RFC 1045                       VMTP                        February 1988 
  2712.  
  2713.  
  2714. 3.3. Request Packet
  2715.  
  2716. The Request packet (or packet group) is sent from the client to the
  2717. server or group of servers to solicit processing plus the return of zero
  2718. or more responses.  A Request packet is identified by a 0 in the LSB of
  2719. the fourth 32-bit word in the packet.
  2720.  
  2721.   0                   1                   2                   3
  2722.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2723.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2724.  +                       Client (8 octets)                       +
  2725.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2726.  |Ver  |                         |H|E|M|                         |
  2727.  |sion |          Domain         |C|P|P|      Length             |
  2728.  |     |                         |O|G|G|                         |
  2729.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2730.  |N|A|N|N|N|M|C|S|D|Retra|Forward|    Inter-     |       |R|R|R| |
  2731.  |R|P|S|E|R|D|M|T|R|nsmit| Count |    Packet     | Prior |E|E|E|0|
  2732.  |S|G|R|R|T|G|G|I|T|Count|       |     Gap       | -ity  |S|S|S| |
  2733.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2734.  |                      Transaction                              |
  2735.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2736.  |                     PacketDelivery                            |
  2737.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2738.  +                    Server (8 octets)                          +
  2739.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2740.  |C|D|M|S|R|C|M|P|                                               |
  2741.  |M|G|D|D|E|R|R|I|        RequestCode                            |
  2742.  |D|M|M|A|S|E|D|C|                                               |
  2743.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2744.  +                 CoResidentEntity (8 octets)                   +
  2745.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2746.  >                   User Data (12 octets)                       <
  2747.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2748.  |                      MsgDelivery                              |
  2749.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2750.  |                       SegmentSize                             |
  2751.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2752.  >                  segment data, if any                         <
  2753.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2754.  |                        Checksum                               |
  2755.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2756.  
  2757.                   Figure 3-1:   Request Packet Format
  2758.  
  2759. The fields of the Request packet are set according to the semantics
  2760. described in Section 3.2 with the following qualifications.
  2761.  
  2762.  
  2763. Cheriton                                                       [page 45]
  2764.  
  2765.  
  2766.  
  2767. RFC 1045                       VMTP                        February 1988 
  2768.  
  2769.  
  2770. InterPacketGap  The estimated interpacket gap time the client would like
  2771.                 for the Response packet group to be sent by the Server
  2772.                 in responding to this Request.
  2773.  
  2774. Transaction     Identifier for transaction, at least one greater than
  2775.                 the previously issued Request from this Client.
  2776.  
  2777. Server          Server to which this Request is destined.
  2778.  
  2779. RequestCode     Request code for this request, indicating the operation
  2780.                 to perform.
  2781.  
  2782.  
  2783.  
  2784.  
  2785.  
  2786.  
  2787.  
  2788.  
  2789.  
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796.  
  2797.  
  2798.  
  2799.  
  2800.  
  2801.  
  2802.  
  2803.  
  2804.  
  2805.  
  2806.  
  2807.  
  2808.  
  2809.  
  2810.  
  2811.  
  2812.  
  2813.  
  2814.  
  2815.  
  2816.  
  2817.  
  2818.  
  2819. Cheriton                                                       [page 46]
  2820.  
  2821.  
  2822.  
  2823. RFC 1045                       VMTP                        February 1988 
  2824.  
  2825.  
  2826. 3.4. Response Packet
  2827.  
  2828. The Response packet is sent from the Server to the Client in response to
  2829. a Request, identified by a 1 in the LSB of the fourth 32-bit word in the
  2830. packet.
  2831.  
  2832.   0                   1                   2                   3
  2833.   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  2834.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2835.  +                       Client (8 octets)                       +
  2836.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2837.  |Ver  |                         |H|E|M|                         |
  2838.  |sion |          Domain         |C|P|P|      Length             |
  2839.  |     |                         |O|G|G|                         |
  2840.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2841.  |N|A|N|N|N|R|C|S|R|Retra|Forward|               |       |R|R|R| |
  2842.  |R|P|S|E|R|E|M|T|E|nsmit| Count |    PGcount    | Prior |E|E|E|1|
  2843.  |S|G|R|R|T|S|G|I|S|Count|       |               | -ity  |S|S|S| |
  2844.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2845.  |                      Transaction                              |
  2846.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2847.  |                      PacketDelivery                           |
  2848.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2849.  +                        Server (8 octets)                      +
  2850.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2851.  |C|D|M|S|R|R|R|R|                                               |
  2852.  |M|G|D|D|E|E|E|E|        ResponseCode                           |
  2853.  |D|M|M|A|S|S|S|S|                                               |
  2854.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2855.  >                   UserData (20 octets)                        <
  2856.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2857.  |                     MsgDelivery                               |
  2858.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2859.  |                    Segment Size                               |
  2860.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2861.  >                  segment data, if any                         <
  2862.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2863.  |                       Checksum                                |
  2864.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2865.  
  2866.                   Figure 3-2:   Response Packet Format
  2867.  
  2868. The fields of the Response packet are set according to the semantics
  2869. described in Section 3.2 with the following qualifications.
  2870.  
  2871. Client, Version, Domain, Transaction
  2872.                 Match those in the Request packet group to which this is
  2873.  
  2874.  
  2875. Cheriton                                                       [page 47]
  2876.  
  2877.  
  2878.  
  2879. RFC 1045                       VMTP                        February 1988 
  2880.  
  2881.  
  2882.                 a response.
  2883.  
  2884. STI             1 if this Response is using one or more of the
  2885.                 transaction identifiers skipped by the Client after the
  2886.                 Request to which this is a Response.  STI in the Request
  2887.                 essentially allocates up to 256 transaction identifiers
  2888.                 for the Server to use in a run of Response packet
  2889.                 groups.
  2890.  
  2891. RetransmitCount The retransmit count from the last Request packet
  2892.                 received to which this is a response.
  2893.  
  2894. ForwardCount    The number of times the corresponding Request was
  2895.                 forwarded before this Response was generated.
  2896.  
  2897. PGcount         The number of consecutively previous packet groups that
  2898.                 this response is acknowledging in addition to the one
  2899.                 identified by the Transaction identifier.
  2900.  
  2901. Server          Server sending this response.  This may differ from that
  2902.                 originally specified in the Request packet if the
  2903.                 original Server was a server group, or the request was
  2904.                 forwarded.
  2905.  
  2906. The next two chapters describes the protocol operation using these
  2907. packet formats, with the the Client and the Server portions described
  2908. separately.
  2909.  
  2910.  
  2911.  
  2912.  
  2913.  
  2914.  
  2915.  
  2916.  
  2917.  
  2918.  
  2919.  
  2920.  
  2921.  
  2922.  
  2923.  
  2924.  
  2925.  
  2926.  
  2927.  
  2928.  
  2929.  
  2930.  
  2931. Cheriton                                                       [page 48]
  2932.  
  2933.  
  2934.  
  2935. RFC 1045                       VMTP                        February 1988 
  2936.  
  2937.  
  2938. 4. Client Protocol Operation
  2939.  
  2940. This chapter describes the operation of the client portion of VMTP in
  2941. terms of the procedures for handling VMTP user events, packet reception
  2942. events, management operations and timeout events.  Note that the client
  2943. portion of VMTP is separable from the server portion.  It is feasible to
  2944. have a node that only implements the client end of VMTP.
  2945.  
  2946. To simplify the description, we define a client state record (CSR) plus
  2947. some standard utility routines.
  2948.  
  2949.  
  2950. 4.1. Client State Record Fields
  2951.  
  2952. In the following protocol description, there is one client state record
  2953. (CSR) per (client,transaction) outstanding message transaction.  Here is
  2954. a suggested set of fields.
  2955.  
  2956. Link            Link to next CSR when queued in one of the transmission,
  2957.                 timeout or message queues.
  2958.  
  2959. QueuePtr        Pointer to queue head in which this CSR is contained or
  2960.                 NULL if none.  Queue could be one of transmission queue,
  2961.                 timeout queue, server queue or response queue.
  2962.  
  2963. ProcessIdentification
  2964.                 The process identification and address space.
  2965.  
  2966. Priority        Priority for processing, network service, etc.
  2967.  
  2968. State           One of the client states described below.
  2969.  
  2970. FinishupFunc    Procedure to be executed on the CSR when it is completes
  2971.                 its processing in transmission or timeout queues.
  2972.  
  2973. TimeoutCount    Time to remain in timeout queue.
  2974.  
  2975. TimeoutLimit    User-specified time after which the message transaction
  2976.                 is aborted. The timeout is infinite if set to zero.
  2977.  
  2978. RetransCount    Number of retransmissions since last hearing from the
  2979.                 Server.
  2980.  
  2981. LastTransmitTime
  2982.                 The time at which the last packet was sent.  This field
  2983.                 is used to calculate roundtrip times, using the
  2984.                 RetransmitCount to match the responding packet to a
  2985.  
  2986.  
  2987. Cheriton                                                       [page 49]
  2988.  
  2989.  
  2990.  
  2991. RFC 1045                       VMTP                        February 1988 
  2992.  
  2993.  
  2994.                 particular transmission.  I.e. Response or management
  2995.                 NotifyVmtpClient operation to Request and a management
  2996.                 NotifyVmtpServer operation to a Response.
  2997.  
  2998. TimetoLive      Time to live to be used on transmission of IP packets.
  2999.  
  3000. TransmissionMask
  3001.                 Bit mask indicating the portions of the segment to
  3002.                 transmit.  Set before entering the transmission queue
  3003.                 and cleared incrementally as the 512-byte segment blocks
  3004.                 of the segment are transmitted.
  3005.  
  3006. LocalClientLink Link to next CSR hashing to same hash index in the
  3007.                 ClientMap.
  3008.  
  3009. LocalClient     Entity identifier for client when this CSR is used to
  3010.                 send a Request packet.
  3011.  
  3012. LocalTransaction
  3013.                 Transaction identifier for current message transaction
  3014.                 the local client has outstanding.
  3015.  
  3016. LocalPrincipal  Account identification, possibly including key and key
  3017.                 timeout.
  3018.  
  3019. LocalDelivery   Bit mask of segment blocks that have not been
  3020.                 acknowledged in the Request or have been received in the
  3021.                 Response, depending on the state.
  3022.  
  3023. ResponseQueue   Queue of CSR's representing the queued Responses for
  3024.                 this entity.
  3025.  
  3026. VMTP Header     Prototype VMTP header, used to generate and store the
  3027.                 header portion of a Request for transmission and
  3028.                 retransmission on timeout.
  3029.  
  3030. SegmentDesc     Description of the segment data associated with the CSR,
  3031.                 either the area storing the original Request data, the
  3032.                 area for receiving Request data, or the area storing the
  3033.                 Response data that is returned.
  3034.  
  3035. HostAddr        The network or internetwork host address to which the
  3036.                 Client last transmitted.  This field also indicates the
  3037.                 type of the address, e.g. IP, Ethernet, etc.
  3038.  
  3039. Note: the CSR can be combined with a light-weight process descriptor
  3040. with considerable benefit if the process is designed to block when it
  3041.  
  3042.  
  3043. Cheriton                                                       [page 50]
  3044.  
  3045.  
  3046.  
  3047. RFC 1045                       VMTP                        February 1988 
  3048.  
  3049.  
  3050. issues a message transaction.  In particular, by combining the two
  3051. descriptors, the implementation saves time because it only needs to
  3052. locate and queue one descriptor with various operations (rather than
  3053. having to locate two descriptors).  It also saves space, given that the
  3054. VMTP header prototype provides space such as the user data field which
  3055. may serve to store processor state for when the process is preempted.
  3056. Non-preemptive blocking can use the process stack to store the processor
  3057. state so only a program counter and stack pointer may be required in the
  3058. process descriptor beyond what we have described.  (This is the approach
  3059. used in the V kernel.)
  3060.  
  3061.  
  3062. 4.2. Client Protocol States
  3063.  
  3064. A Client State Record records the state of message transaction generated
  3065. by this host, identified by the (Client, Transaction) values in the CSR.
  3066. As a client originating a transaction, it is in one of the following
  3067. states.
  3068.  
  3069. AwaitingResponse
  3070.                 Waiting for a Response packet group to arrive with the
  3071.                 same (Client,Transaction) identification.
  3072.  
  3073. ReceivingResponse
  3074.                 Waiting for additional packets in the Response packet
  3075.                 group it is currently receiving.
  3076.  
  3077. "Other"         Not waiting for a response, which can be Processing or
  3078.                 some other operating system state, or one of the Server
  3079.                 states if it also acts as a server.
  3080.  
  3081. This covers all the states for a client.
  3082.  
  3083.  
  3084. 4.3. State Transition Diagrams
  3085.  
  3086. The client state transitions are illustrated in Figure 4-1.  The client
  3087. goes into the state AwaitingResponse on sending a request unless it is a
  3088. datagram request.  In the AwaitingResponse state, it can timeout and
  3089. retry and eventually give up and return to the processing state unless
  3090. it receives a Response.  (A NotifyVmtpClient operation resets the
  3091. timeout but does not change the state.)  On receipt of a single packet
  3092. response, it returns to the processing state.  Otherwise, it goes to
  3093. ReceivingResponse state.  After timeout or final response packet is
  3094. received, the client returns to the processing state.  The processing
  3095. state also includes any other state besides those associated with
  3096. issuing a message transaction.
  3097.  
  3098.  
  3099. Cheriton                                                       [page 51]
  3100.  
  3101.  
  3102.  
  3103. RFC 1045                       VMTP                        February 1988 
  3104.  
  3105.  
  3106.    +------------+
  3107.    | Processing |<--------------------|
  3108.    |            |<-------------|      |
  3109.    |            |<---|         |      |
  3110.    +|------^--^-+  Single    Last     |
  3111.  Transmit  |  |    Packet    Response |
  3112.     |      |  |    Response  Packet   |
  3113.     |      |  |      |         |      |
  3114.     +-DGM->+ Timeout |         |   Final timeout
  3115.     |         |      |         |      |
  3116.    +V-----------+    |       +-----------+
  3117.    |  Awaiting  |----+       | Receiving |->Response-+
  3118.    |  Response  |->Response->| Response  |           |
  3119.    |            |  (multi-   |           |<----------+
  3120.    +-|--------^-+   packet)  +----------^+
  3121.      V        |                |        |
  3122.      +-Timeout+                +>Timeout+
  3123.  
  3124.                  Figure 4-1:   Client State Transitions
  3125.  
  3126.  
  3127. 4.4. User Interface
  3128.  
  3129. The RPC or user interface to VMTP is implementation-dependent and may
  3130. use systems calls, functions or some other mechanism.  The list of
  3131. requests that follow is intended to suggest the basic functionality that
  3132. should be available.
  3133.  
  3134. Send( mcb, timeout, segptr, segsize )
  3135.                 Initiate a message transaction to the server and request
  3136.                 message specified by mcb and return a response in mcb,
  3137.                 if it is received within the specified timeout period
  3138.                 (or else return USER_TIMEOUT in the Code field).  The
  3139.                 segptr parameter specifies the location from which the
  3140.                 segment data is sent and the location into which the
  3141.                 response data is to be delivered.  The segsize field
  3142.                 indicates the maximum length of this area.
  3143.  
  3144. GetResponse( responsemcb, timeout, segptr, segsize )
  3145.                 Get the next response sent to this client as part of the
  3146.                 current message transaction, returning the segment data,
  3147.                 if any, into the memory specified by segptr and segsize.
  3148.  
  3149. This interface assumes that there is a client entity associated with the
  3150. invoking process that is to be used with these operations.  Otherwise,
  3151. the client entity must be specified as an additional parameter.
  3152.  
  3153.  
  3154.  
  3155. Cheriton                                                       [page 52]
  3156.  
  3157.  
  3158.  
  3159. RFC 1045                       VMTP                        February 1988 
  3160.  
  3161.  
  3162. 4.5. Event Processing
  3163.  
  3164. The following events may occur in the VMTP client:
  3165.  
  3166.    - User Requests
  3167.  
  3168.         * Send
  3169.  
  3170.         * GetResponse
  3171.  
  3172.    - Packet Arrival
  3173.  
  3174.         * Response Packet
  3175.  
  3176.         * Request
  3177.  
  3178.      The minimal Client implementation handles Request packets for
  3179.      its VMTP management (server) module and sends NotifyVmtpClient
  3180.      requests in response to others, indicating the specified
  3181.      server does not exist.
  3182.  
  3183.    - Management Operation - NotifyVmtpClient
  3184.  
  3185.    - Timeouts
  3186.  
  3187.         * Client Retransmission Timeout
  3188.  
  3189. The handling of these events is described in detail in the following
  3190. subsections.
  3191.  
  3192. We first describe some conventions and procedures used in the
  3193. description.  A field of the received packet is indicated as (for
  3194. example) p.Transaction, for the Transaction field.  Optional portions of
  3195. the code, such as the streaming handling code are prefixed with a "|" in
  3196. the first column.
  3197.  
  3198. MapClient( client )
  3199.                 Return pointer to CSR for client with the specified
  3200.                 clientId, else NULL.
  3201.  
  3202. SendPacketGroup( csr )
  3203.                 Send the packet group (Request, Response) according to
  3204.                 that specified by the CSR.
  3205.  
  3206. NotifyClient( csr, p, code )
  3207.                 Invoke the NotifyVmtpClient operation with the
  3208.                 parameters csr.RemoteClient, p.control,
  3209.  
  3210.  
  3211. Cheriton                                                       [page 53]
  3212.  
  3213.  
  3214.  
  3215. RFC 1045                       VMTP                        February 1988 
  3216.  
  3217.  
  3218.                 csr.ReceiveSeqNumber, csr.RemoteTransaction and
  3219.                 csr.RemoteDelivery, and code.  If csr is NULL, use
  3220.                 p.Client, p.Transaction and p.PacketDelivery instead and
  3221.                 the global ReceiveSequenceNumber, if supported.  This
  3222.                 function simplifies the description over calling
  3223.                 NotifyVmtpClient directly in the procedural
  3224.                 specification below.  (See Appendix III.)
  3225.  
  3226. NotifyServer( csr, p, code )
  3227.                 Invoke the NotifyVmtpServer operation with the
  3228.                 parameters p.Server, csr.LocalClient,
  3229.                 csr.LocalTransaction, csr.LocalDelivery and code.  Use
  3230.                 p.Client, P.Transaction and 0 for the clientId, transact
  3231.                 and delivery parameters if csr is NULL.  This function
  3232.                 simplifies the description over calling NotifyVmtpServer
  3233.                 directly in the procedural specification below.  (See
  3234.                 Appendix III.)
  3235.  
  3236. DGMset(p)       True if DGM bit set in packet (or csr) else False.
  3237.                 (Similar functions are used for other bits.)
  3238.  
  3239. Timeout( csr, timeperiod, func )
  3240.                 Set or reset timer on csr record for timeperiod later
  3241.                 and invoke func if the timeout expires.
  3242.  
  3243.  
  3244. 4.6. Client User-invoked Events
  3245.  
  3246. A user event occurs when a VMTP user application invokes one of the VMTP
  3247. interface procedures.
  3248.  
  3249.  
  3250. 4.6.1. Send
  3251.  
  3252. Send( mcb, timeout, segptr, segsize )
  3253.     map to main CSR for this client.
  3254.     increment csr.LocalTransaction
  3255.     Init csr and check parameters and segment if any.
  3256.     Set SDA if sending appended data.
  3257.     Flush queued replies from previous transaction, if any.
  3258.     if local non-group server then
  3259.         deliver locally
  3260.         await response
  3261.         return
  3262.     if GroupId(server) then
  3263.         Check for and deliver to local members.
  3264.         if CRE request and non-group local CR entity then
  3265.  
  3266.  
  3267. Cheriton                                                       [page 54]
  3268.  
  3269.  
  3270.  
  3271. RFC 1045                       VMTP                        February 1988 
  3272.  
  3273.  
  3274.            await response
  3275.            return
  3276.         endif
  3277.         set MDG if member of this group.
  3278.     endif
  3279.     clear csr.RetransCount
  3280.     set csr.TransmissionMask
  3281.     set csr.TimeLimit to timeout
  3282.     set csr.HostAddr for csr.Server
  3283.     SendPacketGroup( csr )
  3284.     if DGMset(csr) then
  3285.        return
  3286.     endif
  3287.     set csr.State to AwaitingResponse
  3288.     Timeout( rootcsr, TC1(csr.Server), LocalClientTimeout )
  3289.     return
  3290. end Send
  3291.  
  3292. Notes:
  3293.  
  3294.    1. Normally, the HostAddr is extracted from the ServerHost
  3295.       cache, which maps server entity identifiers to host
  3296.       addresses.  However, on cache miss, the client first queries
  3297.       the network using the ProbeEntity operation, as specified in
  3298.       Appendix III, determining the host address from the Response.
  3299.       The ProbeEntity operation is handled as a separate message
  3300.       transaction by the Client.
  3301.  
  3302. The stream interface incorporates a parameter to pass a responseHandler
  3303. procedure that is invoked when the message transaction completes.
  3304.  
  3305. StreamSend( mcb, timeout, segptr, segsize, responseHandler )
  3306.     map to main CSR for this client.
  3307. |   Allocate a new csr if root in use.
  3308. |   lastcsr := First csr for last request.
  3309. |   if STIset(lastcsr)
  3310. |       csr.LocalTransaction := lastcsr.LocalTransaction + 256
  3311. |   else
  3312. |       csr.LocalTransaction := lastcsr.LocalTransaction + 1
  3313.     Init csr and check parameters and segment if any.
  3314.     . . . ( rest is the same as for the normal Send)
  3315.  
  3316. Notes:
  3317.  
  3318.    1. Each outstanding message transaction is represented by a CSR
  3319.       queued on the root CSR for this client entity.  The root CSR
  3320.       is used to handle timeouts, etc.  On timeout, the last packet
  3321.  
  3322.  
  3323. Cheriton                                                       [page 55]
  3324.  
  3325.  
  3326.  
  3327. RFC 1045                       VMTP                        February 1988 
  3328.  
  3329.  
  3330.       from the last packet group is retransmitted (with or without
  3331.       the segment data).
  3332.  
  3333.  
  3334. 4.6.2. GetResponse
  3335.  
  3336. GetResponse( req, timeout, segptr, segsize )
  3337.     csr := CurrentCSR;
  3338.     if responses queued then return next response
  3339.       (in req, segptr to max of segsize )
  3340.     if timeout is zero then return KERNEL_TIMEOUT error
  3341.     set state to AWAITING_RESPONSE
  3342.     Timeout( csr, timeout, ReturnKernelTimeout );
  3343. end GetResponse
  3344.  
  3345. Notes:
  3346.  
  3347.    1. GetResponse is only used with multicast Requests, which is
  3348.       the only case in which multiple (different) Responses should
  3349.       be received.
  3350.  
  3351.    2. A response must remain queued until the next message
  3352.       transaction is invoked to filter out duplicates of this
  3353.       response.
  3354.  
  3355.    3. If the response is incomplete (only relevant if a
  3356.       multi-packet response), then the client may wait for the
  3357.       response to be fully received, including issuing requests for
  3358.       retransmission (using NotifyVmtpServer operations) before
  3359.       returning the response.
  3360.  
  3361.    4. As an optimization, a response may be stored in the CSR of
  3362.       the client.  In this case, the response must be transferred
  3363.       to a separate buffer (for duplicate suppression) before
  3364.       waiting for another response.  Using this optimization, a
  3365.       response buffer is not allocated in the common case of the
  3366.       client receiving only one response.
  3367.  
  3368.  
  3369. 4.7. Packet Arrival
  3370.  
  3371. In general, on packet reception, a packet is mapped to the client state
  3372. record, decrypted if necessary using the key in the CSR.  It then has
  3373. its checksum verified and then is transformed to the right byte order.
  3374. The packet is then processed fully relative to its packet function code.
  3375. It is discarded immediately if it is addressed to a different domain
  3376. than the domain(s) in which the receiving host participates.
  3377.  
  3378.  
  3379. Cheriton                                                       [page 56]
  3380.  
  3381.  
  3382.  
  3383. RFC 1045                       VMTP                        February 1988 
  3384.  
  3385.  
  3386. For each of the 2 packet types, we assume a procedure called with a
  3387. pointer p to the VMTP packet and psize, the size of the packet in
  3388. octets.  Thus, generic packet reception is:
  3389.  
  3390. if not LocalDomain(p.Domain) then return;
  3391.  
  3392. csr := MapClient( p.Client )
  3393.  
  3394. if csr is NULL then
  3395.     HandleNoCsr( p, psize )
  3396.     return
  3397.  
  3398. if Secure(p) then
  3399.     if SecureVMTP not supported then
  3400.         { Assume a Request. }
  3401.         if not Multicast(p) then
  3402.             NotifyClient(NULL, p, SECURITY_NOT_SUPPORTED )
  3403.         return
  3404.     endif
  3405. |   Decrypt( csr.Key, p, psize )
  3406.  
  3407. if p.Checksum not null then
  3408.     if not VerifyChecksum(p, psize) then return;
  3409. if OppositeByteOrder(p) then ByteSwap( p, psize )
  3410. if psize not equal sizeof(VmtpHeader) + 4*p.Length then
  3411.     NotifyClient(NULL, p, VMTP_ERROR )
  3412.     return
  3413. Invoke Procedure[p.FuncCode]( csr, p, psize )
  3414. Discard packet and return
  3415.  
  3416. Notes:
  3417.  
  3418.    1. The Procedure[p.FuncCode] refers to one of the 2 procedures
  3419.       corresponding to the two different packet types of VMTP,
  3420.       Requests and Responses.
  3421.  
  3422.    2. In all the following descriptions, a packet is discarded on
  3423.       "return" unless otherwise stated.
  3424.  
  3425.    3. The procedure HandleNoCSR is a management routine that
  3426.       allocates and initializes a CSR and processes the packet or
  3427.       else sends an error indication to the sender of the packet.
  3428.       This procedure is described in greater detail in Section
  3429.       4.8.1.
  3430.  
  3431.  
  3432.  
  3433.  
  3434.  
  3435. Cheriton                                                       [page 57]
  3436.  
  3437.  
  3438.  
  3439. RFC 1045                       VMTP                        February 1988 
  3440.  
  3441.  
  3442. 4.7.1. Response
  3443.  
  3444. This procedure handles incoming Response packets.
  3445.  
  3446. HandleResponse( csr, p, psize )
  3447.     if not LocalClient( csr ) then
  3448.         if Multicast then return
  3449. |       if Migrated( p.Client ) then
  3450. |           NotifyServer(csr, p ENTITY_MIGRATED )
  3451. |       else
  3452.             NotifyServer(csr, p, ENTITY_NOT_HERE )
  3453.         return
  3454.     endif
  3455.  
  3456.     if NSRset(p) then
  3457.         if Streaming not supported then
  3458.             NotifyServer(csr, p, STREAMING_NOT_SUPPORTED )
  3459.             return STREAMED_RESPONSE
  3460. |       Find csr corresponding to p.Transaction
  3461. |       if none found then
  3462. |           NotifyServer(csr, p, BAD_TRANSACTION_ID )
  3463. |           return
  3464.      else
  3465.       if csr.LocalTransaction not equal p.Transaction then
  3466.         NotifyServer(csr, p, BAD_TRANSACTION_ID )
  3467.         return
  3468.     endif
  3469.     Locate reply buffer rb for this p.Server
  3470.     if found then
  3471.         if rb.State is not ReceivingResponse then
  3472.           { Duplicate }
  3473.             if APGset(p) or NERset(p) then
  3474.                 { Send Response to stop response packets. }
  3475.                 NotifyServer(csr, p, RESPONSE_DISCARDED )
  3476.             endif
  3477.             return
  3478.          endif
  3479.          { rb.State is ReceivingRequest}
  3480.          if new segment data then retain in CSR segment area.
  3481.          if packetgroup not complete then
  3482.              Timeout( rb, TC3(p.Server), LocalClientTimeout )
  3483.              return;
  3484.           endif
  3485.           goto EndPacketGroup
  3486.     endif
  3487.     { Otherwise, a new response message. }
  3488.  
  3489.  
  3490.  
  3491. Cheriton                                                       [page 58]
  3492.  
  3493.  
  3494.  
  3495. RFC 1045                       VMTP                        February 1988 
  3496.  
  3497.  
  3498.     if (NSRset(p) or NERset(p)) and NoStreaming then
  3499.         NotifyServer(csr, p, VMTP_ERROR )
  3500.         return
  3501. |    if NSRset(p) then
  3502. |      { Check consecutive with previous packet group }
  3503. |       Find last packet group CSR from p.Server.
  3504. |       if p.Transaction not
  3505. |             lastcsr.RemoteTransaction+1 mod 2**32 then
  3506. |         { Out of order packet group }
  3507. |            NotifyServer(csr, p, BAD_TRANSACTION_ID)
  3508. |           return
  3509. |       endif
  3510. |       if lastcsr not completed then
  3511. |           NotifyServer(lastcsr, p, RETRY )
  3512. |       endif
  3513. |       if CMG(lastcsr) then
  3514. |           Add segment data to lastcsr Response
  3515. |           Notify lastcsr with new packet group.
  3516. |           Clear lastcsr.VerifyInterval
  3517. |       else
  3518. |           if lastcsr available then
  3519. |                 use it for this packet group
  3520. |           else allocate and initialize new CSR
  3521. |           Save message and segment data in new CSR area.
  3522. |       endif
  3523. |   else { First packet group }
  3524.         Allocate and init reply buffer rb for this response.
  3525.         if allocation fails then
  3526.             NotifyServer(csr, p, BUSY )
  3527.             return
  3528.         Set rb.State to ReceivingResponse
  3529.         Copy message and segment data to rb's segment area
  3530.          and set rb.PacketDelivery to that delivered.
  3531.         Save p.Server host address in ServerHost cache.
  3532.     endif
  3533.     if packetgroup not complete then
  3534.         Timeout( rb, TS1(p.Client), LocalClientTimeout )
  3535.         return;
  3536.     endif
  3537. endPacketGroup:
  3538.     { We have received last packet in packet group. }
  3539.     if APGset(p) then NotifyServer(csr, p, OK )
  3540. |   if NERset(p) and CMGset(p) then
  3541. |       Queue waiting for continuation packet group.
  3542. |       Timeout( rb, TC2(rb.Server), LocalClientTimeout )
  3543. |       return
  3544. |   endif
  3545.  
  3546.  
  3547. Cheriton                                                       [page 59]
  3548.  
  3549.  
  3550.  
  3551. RFC 1045                       VMTP                        February 1988 
  3552.  
  3553.  
  3554.     { Deliver response message. }
  3555.     Deliver response to Client, or queue as appropriate.
  3556. end HandleResponse
  3557.  
  3558. Notes:
  3559.  
  3560.    1. The mechanism for handling streaming is optional and can be
  3561.       replaced with the tests for use of streaming.  Note that the
  3562.       server should never stream at the Client unless the Client
  3563.       has streamed at the Server or has used the STI control bit.
  3564.       Otherwise, streamed Responses are a protocol error.
  3565.  
  3566.    2. As an optimization, a Response can be stored into the CSR for
  3567.       the Client rather than allocating a separate CSR for a
  3568.       response buffer.  However, if multiple responses are handled,
  3569.       the code must be careful to perform duplicate detection on
  3570.       the Response stored there as well as those queued.  In
  3571.       addition, GetResponse must create a queued version of this
  3572.       Response before allowing it to be overwritten.
  3573.  
  3574.    3. The handling of Group Responses has been omitted for brevity.
  3575.       Basically, a Response is accepted if there has been a Request
  3576.       received locally from the same Client and same Transaction
  3577.       that has not been responded to.  In this case, the Response
  3578.       is delivered to the Server or queued.
  3579.  
  3580.  
  3581.  
  3582.  
  3583.  
  3584.  
  3585.  
  3586.  
  3587.  
  3588.  
  3589.  
  3590.  
  3591.  
  3592.  
  3593.  
  3594.  
  3595.  
  3596.  
  3597.  
  3598.  
  3599.  
  3600.  
  3601.  
  3602.  
  3603. Cheriton                                                       [page 60]
  3604.  
  3605.  
  3606.  
  3607. RFC 1045                       VMTP                        February 1988 
  3608.  
  3609.  
  3610. 4.8. Management Operations
  3611.  
  3612. VMTP uses management operations (invoked as remote procedure calls) to
  3613. effectively acknowledge packet groups and request retransmissions.  The
  3614. following routine is invoked by the Client's management module on
  3615. request from the Server.
  3616.  
  3617. NotifyVmtpClient( clientId,ctrl,receiveSeqNumber,transact,delivery,code)
  3618.     Get csr for clientId
  3619.     if none then return
  3620.     if RemoteClient( csr ) and not NotifyVmtpRemoteClient then
  3621.        return
  3622. |   else (for streaming)
  3623. |      Find csr with same LocalTransaction as transact
  3624. |      if csr is NULL then return
  3625.     if csr.State not AwaitingResponse then return
  3626.     if ctrl.PGcount then ack previous packet groups.
  3627.     select on code
  3628.       case OK:
  3629.         Notify ack'ed segment blocks from delivery
  3630.         Clear csr.RetransCount;
  3631.         Timeout( csr, TC1(csr.Server), LocalClientTimeout )
  3632.         return
  3633.       case RETRY:
  3634.         Set csr.TransmissionMask to missing segment blocks,
  3635.             as specified by delivery
  3636.         SendPacketGroup( csr )
  3637.         Timeout( csr, TC1(csr.Server), LocalClientTimeout )
  3638.       case RETRY_ALL
  3639.         Set csr.TransmissionMask to retransmit all blocks.
  3640.         SendPacketGroup( csr )
  3641.         Timeout( csr, TC1(csr.Server), LocalClientTimeout )
  3642. |       if streaming then
  3643. |          Restart transmission of packet groups,
  3644. |                starting from transact+1
  3645.          return
  3646.       case BUSY:
  3647.          if csr.TimeLimit exceeded then
  3648.              Set csr.Code to USER_TIMEOUT
  3649.              return Response to application
  3650.              return;
  3651.         Set csr.TransmissionMask for full retransmission
  3652.         Clear csr.RetransCount
  3653.         Timeout( csr, TC1(csr.Server), LocalClientTimeout )
  3654.         return
  3655.       case ENTITY_MIGRATED:
  3656.         Get new host address for entity
  3657.  
  3658.  
  3659. Cheriton                                                       [page 61]
  3660.  
  3661.  
  3662.  
  3663. RFC 1045                       VMTP                        February 1988 
  3664.  
  3665.  
  3666.         Set csr.TransmissionMask for full retransmission
  3667.         Clear csr.RetransCount
  3668.         SendPacketGroup( csr )
  3669.         Timeout( csr, TC1(csr.Server), LocalClientTimeout )
  3670.         return
  3671.  
  3672.       case STREAMING_NOT_SUPPORTED:
  3673.         Record that server does not support streaming
  3674.         if CMG(csr) then forget this packet group
  3675.         else resend Request as separate packet group.
  3676.         return
  3677.       default:
  3678.          Set csr.Code to code
  3679.          return Response to application
  3680.          return;
  3681.     endselect
  3682. end NotifyVmtpClient
  3683.  
  3684. Notes:
  3685.  
  3686.    1. The delivery parameter indicates the segment blocks received
  3687.       by the Server.  That is, a 1 bit in the i-th position
  3688.       indicates that the i-th segment block in the segment data of
  3689.       the Request was received.  All subsequent NotifyVmtpClient
  3690.       operations for this transaction should be set to acknowledge
  3691.       a superset of the segment blocks in this packet.  In
  3692.       particular, the Client need not be prepared to retransmit the
  3693.       segment data once it has been acknowledged by a Notify
  3694.       operation.
  3695.  
  3696.  
  3697. 4.8.1. HandleNoCSR
  3698.  
  3699. HandleNoCSR is called when a packet arrives for which there is no CSR
  3700. matching the client field of the packet.
  3701.  
  3702. HandleNoCSR( p, psize )
  3703.     if Secure(p) then
  3704.         if SecureVMTP not supported then
  3705.             { Assume a Request }
  3706.             if not Multicast(p) then
  3707.                 NotifyClient(NULL,p,SECURITY_NOT_SUPPORTED)
  3708.             return
  3709.         endif
  3710.         HandleRequestNoCSR( p, psize )
  3711.         return
  3712.     endif
  3713.  
  3714.  
  3715. Cheriton                                                       [page 62]
  3716.  
  3717.  
  3718.  
  3719. RFC 1045                       VMTP                        February 1988 
  3720.  
  3721.  
  3722.     if p.Checksum not null then
  3723.         if not VerifyChecksum(p, psize) then return;
  3724.     if OppositeByteOrder(p) then ByteSwap( p, psize )
  3725.     if psize not equal sizeof(VmtpHeader) + 4*p.Length then
  3726.         NotifyClient(NULL, p, VMTP_ERROR )
  3727.         return
  3728.  
  3729.     if p.FuncCode is Response then
  3730. |        if Migrated( p.Client ) then
  3731. |           NotifyServer(csr, p ENTITY_MIGRATED )
  3732. |       else
  3733.             NotifyServer(csr, p, NONEXISTENT_ENTITY )
  3734.         return
  3735.     endif
  3736.  
  3737.     if p.FuncCode is Request then
  3738.        HandleRequestNoCSR( p, psize )
  3739.     return
  3740. end HandleNoCSR
  3741.  
  3742. Notes:
  3743.  
  3744.    1. The node need only check to see if the client entity has
  3745.       migrated if in fact it supports migration of entities.
  3746.  
  3747.    2. The procedure HandleRequestNoCSR is specified in Section
  3748.       5.8.1.  In the minimal client version, it need only handle
  3749.       Probe requests and can do so directly without allocating a
  3750.       new CSR.
  3751.  
  3752.  
  3753.  
  3754.  
  3755.  
  3756.  
  3757.  
  3758.  
  3759.  
  3760.  
  3761.  
  3762.  
  3763.  
  3764.  
  3765.  
  3766.  
  3767.  
  3768.  
  3769.  
  3770.  
  3771. Cheriton                                                       [page 63]
  3772.  
  3773.  
  3774.  
  3775. RFC 1045                       VMTP                        February 1988 
  3776.  
  3777.  
  3778. 4.9. Timeouts
  3779.  
  3780. A client with a message transaction in progress has a single timer
  3781. corresponding to the first unacknowledged request message.  (In the
  3782. absence of streaming, this request is also the last request sent.)  This
  3783. timeout is handled as follows:
  3784.  
  3785. LocalClientTimeout( csr )
  3786.   select on csr.State
  3787.     case AwaitingResponse:
  3788.       if csr.RetransCount > MaxRetrans(csr.Server) then
  3789.              terminate Client's message transactions up to
  3790.              and including the current message transaction.
  3791.              set return code to KERNEL_TIMEOUT
  3792.           return
  3793.       increment csr.RetransCount
  3794.       Resend current packet group with APG set.
  3795.       Timeout( csr, TC2(csr.Server), LocalClientTimeout )
  3796.       return
  3797.     case ReceivingResponse:
  3798.       if DGMset(csr) or csr.RetransCount > Max then
  3799.          if MDMset(csr) then
  3800.             Set MCB.MsgDeliveryMask to blocks received.
  3801.          else
  3802.             Set csr.Code to BAD_REPLY_SEGMENT
  3803.          return to user Client
  3804.       endif
  3805.       increment csr.RetransCount
  3806.       NotifyServer with RETRY
  3807.       Timeout( csr, TC3(csr.Server), LocalClientTimeout )
  3808.       return
  3809.   end select
  3810. end LocalClientTimeout
  3811.  
  3812. Notes:
  3813.  
  3814.    1. A Client can only request retransmission of a Response if the
  3815.       Response is not idempotent.  If idempotent, it must
  3816.       retransmit the Request.  The Server should generally support
  3817.       the MsgDeliveryMask for Requests that it treats as idempotent
  3818.       and that require multi-packet Responses.  Otherwise, there is
  3819.       no selective retransmission for idempotent message
  3820.       transactions.
  3821.  
  3822.    2. The current packet group is the last one transmitted.  Thus,
  3823.       with streaming, there may be several packet groups
  3824.       outstanding that precede the current packet group.
  3825.  
  3826.  
  3827. Cheriton                                                       [page 64]
  3828.  
  3829.  
  3830.  
  3831. RFC 1045                       VMTP                        February 1988 
  3832.  
  3833.  
  3834.    3. The Request packet group should be retransmitted without the
  3835.       segment data, resulting in a single short packet in the
  3836.       retransmission.  The Server must then send a
  3837.       NotifyVmtpClient with a RETRY or RETRY_ALL code to get the
  3838.       segment data transmitted as needed.  This strategy minimizes
  3839.       the overhead on the network and the server(s) for
  3840.       retransmissions.
  3841.  
  3842.  
  3843.  
  3844.  
  3845.  
  3846.  
  3847.  
  3848.  
  3849.  
  3850.  
  3851.  
  3852.  
  3853.  
  3854.  
  3855.  
  3856.  
  3857.  
  3858.  
  3859.  
  3860.  
  3861.  
  3862.  
  3863.  
  3864.  
  3865.  
  3866.  
  3867.  
  3868.  
  3869.  
  3870.  
  3871.  
  3872.  
  3873.  
  3874.  
  3875.  
  3876.  
  3877.  
  3878.  
  3879.  
  3880.  
  3881.  
  3882.  
  3883. Cheriton                                                       [page 65]
  3884.  
  3885.  
  3886.  
  3887. RFC 1045                       VMTP                        February 1988 
  3888.  
  3889.  
  3890. 5. Server Protocol Operation
  3891.  
  3892. This section describes the operation of the server portion of the
  3893. protocol in terms of the procedures for handling VMTP user events,
  3894. packet reception events and timeout events.  Each server is assumed to
  3895. implement the client procedures described in the previous chapter.
  3896. (This is not strictly necessary but it simplifies the exposition.)
  3897.  
  3898.  
  3899. 5.1. Remote Client State Record Fields
  3900.  
  3901. The CSR for a server is extended with the following fields, in addition
  3902. to the ones listed for the client version.
  3903.  
  3904. RemoteClient    Identifier for remote client that sent the Request that
  3905.                 this CSR is handling.
  3906.  
  3907. RemoteClientLink
  3908.                 Link to next CSR hashing to same hash index in the
  3909.                 ClientMap.
  3910.  
  3911. RemoteTransaction
  3912.                 Transaction identifier for Request from remote client.
  3913.  
  3914. RemoteDelivery  The segment blocks received so far as part of a Request
  3915.                 or yet to be acknowledged as part of a Response.
  3916.  
  3917. VerifyInterval  Time interval since there was confirmation that the
  3918.                 remote Client was still valid.
  3919.  
  3920. RemotePrincipal Account identification, possibly including key and key
  3921.                 timeout for secure communication.
  3922.  
  3923.  
  3924. 5.2. Remote Client Protocol States
  3925.  
  3926. A CSR in the server end is in one of the following states.
  3927.  
  3928. AwaitingRequest Waiting for a Request packet group.  It may be marked as
  3929.                 waiting on a specific Client, or on any Client.
  3930.  
  3931. ReceivingRequest
  3932.                 Waiting to receive additional Request packets in a
  3933.                 multi-packet group Request.
  3934.  
  3935. Responded       The Response has been sent and the CSR is timing out,
  3936.                 providing duplicate suppression and retransmission (if
  3937.  
  3938.  
  3939. Cheriton                                                       [page 66]
  3940.  
  3941.  
  3942.  
  3943. RFC 1045                       VMTP                        February 1988 
  3944.  
  3945.  
  3946.                 the Response was not idempotent).
  3947.  
  3948. ResponseDiscarded
  3949.                 Response has been acknowledged or has timed out so
  3950.                 cannot be retransmitted.  However, duplicates are still
  3951.                 filtered and CSR can be reused for new message
  3952.                 transaction.
  3953.  
  3954. Processing      Executing on behalf of the Client.
  3955.  
  3956. Forwarded       The message transaction has been forwarded to another
  3957.                 Server that is to respond directly to the Client.
  3958.  
  3959.  
  3960. 5.3. State Transition Diagrams
  3961.  
  3962. The CSR state transitions in the server are illustrated in Figure 5-1.
  3963. The CSR generally starts in the AwaitingRequest state.  On receipt of a
  3964. Request, the Server either has an up-to-date CSR for the Client or else
  3965. it sends a Probe request (as a separate VMTP message transaction) to the
  3966. VMTP management module associated with the Client.  In the latter case,
  3967. the processing of the Request is delayed until a Response to the Probe
  3968. request is received.  At that time, the CSR information is brought up to
  3969. date and the Request is processed.  If the Request is a single-packet
  3970. request, the CSR is then set in the Processing state to handle the
  3971. request.  Otherwise (a multi-packet Request), the CSR is put into the
  3972. ReceivingResponse state, waiting to receive subsequent Request packets
  3973. that constitute the Request message.  It exits the ReceivingRequest
  3974. state on timeout or on receiving the last Request packet.  In the former
  3975. case, the request is delivered with an indication of the portion
  3976. received, using the MsgDelivery field if MDM is set.  After request
  3977. processing is complete, either the Response is sent and the CSR enters
  3978. the Responded state or the message transaction is forwarded and the CSR
  3979. enters the Forwarded state.
  3980.  
  3981. In the Responded state, if the Response is not marked as idempotent, the
  3982. Response is retransmitted on receipt of a retransmission of the
  3983. corresponding Request, on receipt of a NotifyVmtpServer operation
  3984. requesting retransmission or on timeout at which time APG is set,
  3985. requesting an acknowledgment from the Client.  The Response is
  3986. retransmitted some maximum number of times at which time the Response is
  3987. discarded and the CSR is marked accordingly.  If a Request or a
  3988. NotifyVmtpServer operation is received expecting retransmission of the
  3989. Response after the CSR has entered the ResponseDiscarded state, a
  3990. NotifyVmtpClient operation is sent back (or invoked in the Client
  3991. management module) indicating that the response was discarded unless the
  3992. Request was multicast, in which case no action is taken.  After a
  3993.  
  3994.  
  3995. Cheriton                                                       [page 67]
  3996.  
  3997.  
  3998. RFC 1045                       VMTP                        February 1988 
  3999.  
  4000.  
  4001.      (Retransmit Forwarded Request and NotifyVmtpClient)
  4002.                     Request/
  4003.                     Ack/
  4004.                    +Timeout+
  4005.                    V       |
  4006.                  +-|-------^-+
  4007.                  |           |
  4008.           +-Time-| Forwarded |<-------------+
  4009.           |  out +-----------+              |
  4010.           |                                 |
  4011.           |          (Retransmit Response)  |
  4012.           |                      Request    |
  4013.           V                      Ack        |
  4014.           |                    +-Timeout-+  |
  4015.           |                    V         |  |
  4016.         +---------+ Ack/ +|---------^+ |
  4017.  +-Time-|Response |<-Timeout--| Responded | |
  4018.  |  out |Discarded|           +----^------+ |
  4019.  |      +---------+                |        |
  4020.  |  +------------+                 |        |
  4021.  |  |            |->-Send Response-+        |
  4022.  |  |            |->-forward Request--------+
  4023.  +->| Processing |<----------------------+
  4024.  |  |            |<----------------+     |
  4025.  |  |            |<---|            |     |
  4026.  |  +-|--------^-+    |          Last    |
  4027.  | Receive     |      |          Request |
  4028.  |    |   Timeout   Single       Packet  |
  4029.  |    |        |    Packet         |   Timeout
  4030.  |    |        |    Request        ^     ^
  4031.  |    |        |      ^           +|-----|--+
  4032.  |  +-V--------|-+    |           |Receiving|<-+Time
  4033.  +->|  Awaiting  |->--+->Request->| Request |--+ out
  4034.     |  Request   |    |  (multi-  +---------+
  4035.     +------|-----+    ^  packet)
  4036.         Request       |
  4037.            |        Response
  4038.       Send Probe     to
  4039.            |        Probe
  4040.        +---V----+     |
  4041.        |Awaiting|     ^
  4042.        |Response|-->--+
  4043.        |to Probe|
  4044.        +--------+
  4045.  
  4046.              Figure 5-1:   Remote Client State Transitions
  4047.  
  4048. timeout corresponding to the time required to filter out duplicates, the
  4049.  
  4050. Cheriton                                                       [page 68]
  4051.  
  4052.  
  4053.  
  4054. RFC 1045                       VMTP                        February 1988 
  4055.  
  4056.  
  4057. CSR returns either to the AwaitingRequest state or to the Processing
  4058. state.  Note that "Ack" refers to acknowledgment by a Notify operation.
  4059.  
  4060. A Request that is forwarded leaves the CSR in the Forwarded state.  In
  4061. the Forwarded state, the forwarded Request is retransmitted
  4062. periodically, expecting NotifyRemoteClient operations back from the
  4063. Server to which the Request was forwarded, analogous to the Client
  4064. behavior in the AwaitingResponse state.  In this state, a
  4065. NotifyRemoteClient from this Server acknowledges the Request or asks
  4066. that it be retransmitted or reports an error.  A retransmission of the
  4067. Request from the Client causes a NotifyVmtpClient to be returned to the
  4068. Client if APG is set.  The CSR leaves the Forwarded state after timing
  4069. out in the absence of NotifyRemoteClient operations from the forward
  4070. Server or on receipt of a NotifyRemoteClient operation indicating the
  4071. forward Server has sent a Response and received an acknowledgement.  It
  4072. then enters the ResponseDiscarded state.
  4073.  
  4074. Receipt of a new Request from the same Client aborts the current
  4075. transaction, independent of its state, and initiates a new transaction
  4076. unless the new Request is part of a run of message transactions.  If it
  4077. is part of a run of message transactions, the handling follows the state
  4078. diagram except the new Request is not Processed until there has been a
  4079. response sent to the previous transaction.
  4080.  
  4081.  
  4082. 5.4. User Interface
  4083.  
  4084. The RPC or user interface to VMTP is implementation-dependent and may
  4085. use systems calls, functions or some other mechanism.  The list of
  4086. requests that follow is intended to suggest the basic functionality that
  4087. should be available.
  4088.  
  4089. AcceptMessage( reqmcb, segptr, segsize, client, transid, timeout ) 
  4090.                 Accept a new Request message in the specified reqmcb
  4091.                 area, placing the segment data, if any, in the area
  4092.                 described by segptr and segsize.  This returns the
  4093.                 Server in the entityId field of the reqmcb and actual
  4094.                 segment size in the segsize parameters.  It also returns
  4095.                 the Client and Transaction for this message transaction
  4096.                 in the corresponding parameters.  This procedure
  4097.                 supports message semantics for request processing.  When
  4098.                 a server process executes this call, it blocks until a
  4099.                 Request message has been queued for the server.
  4100.                 AcceptMessage returns after the specified timeout period
  4101.                 if a message has not been received by that time.
  4102.  
  4103. RespondMessage( responsemcb, client, transid, segptr ) 
  4104.  
  4105.  
  4106. Cheriton                                                       [page 69]
  4107.  
  4108.  
  4109.  
  4110. RFC 1045                       VMTP                        February 1988 
  4111.  
  4112.  
  4113.                 Respond to the client with the specified response
  4114.                 message and segment, again with message semantics.
  4115.  
  4116. RespondCall( responsemcb, segptr ) 
  4117.                 Respond to the client with the specified response
  4118.                 message and segment, with remote procedure call
  4119.                 semantics.  This procedure does not return.  The
  4120.                 lightweight process that executes this procedure is
  4121.                 matched to a stack, program counter, segment area and
  4122.                 priority from the information provided in a
  4123.                 ModifyService call, as specified in Appendix III.
  4124.  
  4125. ForwardMessage( requestmcb, transid, segptr, segsize, forwardserver ) 
  4126.                 Forward the client to the specified forwardserver with
  4127.                 the request specified in mcb.
  4128.  
  4129. ForwardCall( requestmcb, segptr, segsize, forwardserver ) 
  4130.                 Forward the client transaction to the specified
  4131.                 forwardserver with the request specified by requestmcb.
  4132.                 This procedure does not return.
  4133.  
  4134. GetRemoteClientId()
  4135.                 Return the entityId for the remote client on whose
  4136.                 behave the process is executing.  This is only
  4137.                 applicable in the procedure call model of request
  4138.                 handling.
  4139.  
  4140. GetForwarder( client )
  4141.                 Return the entity that forwarded this Request, if any.
  4142.  
  4143. GetProcess( client )
  4144.                 Return an identifier for the process associated with
  4145.                 this client entity-id.
  4146.  
  4147. GetPrincipal( client )
  4148.                 Return the principal associated with this client
  4149.                 entity-id.
  4150.  
  4151.  
  4152. 5.5. Event Processing
  4153.  
  4154. The following events may occur in VMTP servers.
  4155.  
  4156.    - User Requests
  4157.  
  4158.         * Receive
  4159.  
  4160.  
  4161.  
  4162. Cheriton                                                       [page 70]
  4163.  
  4164.  
  4165.  
  4166. RFC 1045                       VMTP                        February 1988 
  4167.  
  4168.  
  4169.         * Respond
  4170.  
  4171.         * Forward
  4172.  
  4173.         * GetForwarder
  4174.  
  4175.         * GetProcess
  4176.  
  4177.         * GetPrincipal
  4178.  
  4179.    - Packet Arrival
  4180.  
  4181.         * Request Packet
  4182.  
  4183.    - Management Operations
  4184.  
  4185.         * NotifyVmtpServer
  4186.  
  4187.    - Timeouts
  4188.  
  4189.         * Client State Record Timeout
  4190.  
  4191. The handling of these events is described in detail in the following
  4192. subsections.  The conventions of the previous chapter are followed,
  4193. including the use of the various subroutines in the description.
  4194.  
  4195.  
  4196. 5.6. Server User-invoked Events
  4197.  
  4198. A user event occurs when a VMTP server invokes one of the VMTP interface
  4199. procedures.
  4200.  
  4201.  
  4202. 5.6.1. Receive
  4203.  
  4204. AcceptMessage(reqmcb, segptr, segsize, client, transid, timeout)
  4205.     Locate server's request queue.
  4206.     if request is queued then
  4207.         Remember CSR associated with this Request.
  4208.         return Request in reqmcb, segptr and segsize
  4209.                and client and transaction id.
  4210.     Wait on server's request queue for next request
  4211.     up time timeout seconds.
  4212. end ReceiveCall
  4213.  
  4214. Notes:
  4215.  
  4216.  
  4217.  
  4218. Cheriton                                                       [page 71]
  4219.  
  4220.  
  4221.  
  4222. RFC 1045                       VMTP                        February 1988 
  4223.  
  4224.  
  4225.    1. If a multi-packet Request is partially received at the time
  4226.       of the AcceptMessage, the process waits until it completes.
  4227.  
  4228.    2. The behavior of a process accepting a Request as a
  4229.       lightweight thread is similar except that the process
  4230.       executes using the Request data logically as part of the
  4231.       requesting Client process.
  4232.  
  4233.  
  4234. 5.6.2. Respond
  4235.  
  4236. RespondCall is described as one case of the Respond transmission
  4237. procedure; RespondMessage is similar.
  4238.  
  4239. RespondCall( responsemcb, responsesegptr )
  4240.     Locate csr for this client.
  4241.     Check segment data accessible, if any
  4242.     if local client then
  4243.         Handle locally
  4244.         return
  4245.     endif
  4246.     if responsemcb.Code is RESPONSE_DISCARDED then
  4247.         Mark as RESPONSE_DISCARDED
  4248.         return
  4249.     SendPacketGroup( csr )
  4250.     set csr.State to Responded.
  4251.     if DGM reply then { Idempotent }
  4252.         release segment data
  4253.         Timeout( csr, TS4(csr.Client), FreeCsr );
  4254.     else { Await acknowledgement or new Request else ask for ack. }
  4255.         Timeout( csr, TS5(csr.Client), RemoteClientTimeout )
  4256. end RespondCall
  4257.  
  4258. Notes:
  4259.  
  4260.    1. RespondMessage is similar except the Server process must be
  4261.       synchronized with the release of the segment data (if any).
  4262.  
  4263.    2. The non-idempotent Response with segment data is sent first
  4264.       without a request for an acknowledgement.  The Response is
  4265.       retransmitted after time TS5(client) if no acknowledgment or
  4266.       new Request is received from the client in the meantime.  At
  4267.       this point, the APG bit is sent.
  4268.  
  4269.    3. The MCB of the Response is buffered in the client CSR, which
  4270.       remains for TS4 seconds, sufficient to filter old duplicates.
  4271.       The segment data (if any) must be retained intact until:  (1)
  4272.  
  4273.  
  4274. Cheriton                                                       [page 72]
  4275.  
  4276.  
  4277.  
  4278. RFC 1045                       VMTP                        February 1988 
  4279.  
  4280.  
  4281.       after transmission if idempotent or (2) after acknowledged or
  4282.       timeout has occurred if not idempotent.  Techniques such as
  4283.       copy-on-write might be used to keep a copy of the Response
  4284.       segment data without incurring the cost of a copy.
  4285.  
  4286.  
  4287. 5.6.3. Forward
  4288.  
  4289. Forwarding is logically initiating a new message transaction between the
  4290. Server (now acting as a Client) and the server to which the Request is
  4291. forwarded.  When the second server returns a Response, the same Response
  4292. is immediately returned to the Client.  The forwarding support in VMTP
  4293. preserves these semantics while providing some performance optimizations
  4294. in some cases.
  4295.  
  4296. ForwardCall( req, segptr, segsize, forwardserver )
  4297.     Locate csr for this client.
  4298.     Check segment data accessible, if any
  4299.  
  4300.     if local client or Request was multicast or secure
  4301.        or csr.ForwardCount == 15 then
  4302.         Handle as a new Send operation
  4303.         return
  4304.     if forwardserver is local then
  4305.         Handle locally
  4306.         return
  4307.     Set csr.funccode to Request
  4308.     Increment csr.ForwardCount
  4309.     Set csr.State to Responded
  4310.     SendPacketGroup( csr ) { To ForwardServer }
  4311.     Timeout( csr, TS4(csr.Client), FreeAlien )
  4312. end ForwardCall
  4313.  
  4314. Notes:
  4315.  
  4316.    1. A Forward is logically a new call or message transaction.  It
  4317.       must be really implemented as a new message transaction if
  4318.       the original Request was multicast or secure (with the
  4319.       optional further refinement that it can be used with a secure
  4320.       message transaction when the Server and ForwardServer are the
  4321.       same principal and the Request was not multicast).
  4322.  
  4323.    2. A Forward operation is never handled as an idempotent
  4324.       operation because it requires knowledge that the
  4325.       ForwardServer will treat the forwarded operation as
  4326.       idempotent as well.  Thus, a Forward operation that includes
  4327.       a segment should set APG on the first transmission of the
  4328.  
  4329.  
  4330. Cheriton                                                       [page 73]
  4331.  
  4332.  
  4333.  
  4334. RFC 1045                       VMTP                        February 1988 
  4335.  
  4336.  
  4337.       forwarded Request to get an acknowledgement for this data.
  4338.       Once the acknowledgement is received, the forwarding Server
  4339.       can discard the segment data, leaving only the basic CSR to
  4340.       handle retransmissions from the Client.
  4341.  
  4342.  
  4343. 5.6.4. Other Functions
  4344.  
  4345. GetRemoteClient is a simple local query of the CSR.  GetProcess and
  4346. GetPrincipal also extract this information from the CSR.  A server
  4347. module may defer the Probe callback to the Client to get that
  4348. information until it is requested by the Server (assuming it is not
  4349. using secure communication and duplicate suppression is adequate without
  4350. callback.)  GetForwarder is implemented as a callback to the Client,
  4351. using a GetRequestForwarder VMTP management operation.  Additional
  4352. management procedures for VMTP are described in Appendix III.
  4353.  
  4354.  
  4355. 5.7. Request Packet Arrival
  4356.  
  4357. The basic packet reception follows that described for the Client
  4358. routines.  A Request packet is handled by the procedure HandleRequest.
  4359.  
  4360. HandleRequest( csr, p, psize )
  4361.  
  4362.     if LocalClient(csr) then
  4363.         { Forwarded Request on local Client }
  4364.         if csr.LocalTransaction != p.Transaction then return
  4365.         if csr.State != AwaitingResponse then return
  4366.         if p.ForwardCount < csr.ForwardCount then
  4367.            Discard Request and return.
  4368.         Find a CSR for Client as a remote Client.
  4369.         if not found then
  4370.             if packet group complete then
  4371.                 handle as a local message transaction
  4372.                 return
  4373.             Allocate and init CSR
  4374.             goto newTransaction
  4375.         { Otherwise part of current transaction }
  4376.         { Handle directly below. }n
  4377.     if csr.RemoteTransaction = p.Transaction then
  4378.       { Matches current transaction }
  4379.         if OldForward(p.ForwardCount,csr.ForwardCount) then
  4380.             return
  4381.         if p.ForwardCount > csr.ForwardCount then
  4382.           { New forwarded transaction }
  4383.             goto newTransaction
  4384.  
  4385.  
  4386. Cheriton                                                       [page 74]
  4387.  
  4388.  
  4389.  
  4390. RFC 1045                       VMTP                        February 1988 
  4391.  
  4392.  
  4393.         { Otherwise part of current transaction }
  4394.         if csr.State = ReceivingRequest then
  4395.             if new segment data then retain in CSR segment area.
  4396.             if Request not complete then
  4397.                Timeout( csr, TS1(p.Client), RemoteClientTimeout )
  4398.                return;
  4399.             endif
  4400.             goto endPacketGroup
  4401.         endif
  4402.         if csr.State is Responded then
  4403.           { Duplicate }
  4404.             if csr.Code is RESPONSE_DISCARDED
  4405.                and Multicast(p) then
  4406.                 return
  4407.             endif
  4408.             if not DGM(csr) then { Not idempotent }
  4409.                 if SegmentData(csr) then set APG
  4410.                 { Resend Response or Request, if Forwarded }
  4411.                 SendPacketGroup( csr )
  4412.                 timeout=if SegmentData(csr) then TS5(csr.Client)
  4413.                           else TS4(csr.Client)
  4414.                 Timeout( csr, timeout, RemoteClientTimeout )
  4415.                 return
  4416.             { Else idempotent - fall thru to newTransaction }
  4417.         else { Presume it is a retransmission }
  4418.             NotifyClient( csr, p, OK )
  4419.             return
  4420.    else if OldTransaction(csr.RemoteTransact,p.Transaction) then
  4421.         return
  4422.     { Otherwise, a new message transaction. }
  4423. newTransaction:
  4424.     Abort handling of previous transactions for this Client.
  4425.  
  4426.     if (NSRset(p) or NERset(p)) and NoStreaming then
  4427.         NotifyClient( csr, p, STREAMING_NOT_SUPPORTED )
  4428.         return
  4429. |   if NSRset(p) then { Streaming }
  4430. |     { Check that consecutive with previous packet group }
  4431. |       Find last packet group CSR from this client.
  4432. |      if p.Transaction not lastcsr.RemoteTransaction+1 mod 2**32
  4433. |         and not STIset(lastcsr) or
  4434. |        p.Transaction not lastcsr.RemoteTransaction+256 mod **32
  4435. |        then
  4436. |         { Out of order packet group }
  4437. |         NotifyClient(csr, p, BAD_TRANSACTION_ID )
  4438. |         return
  4439. |       endif
  4440.  
  4441.  
  4442. Cheriton                                                       [page 75]
  4443.  
  4444.  
  4445.  
  4446. RFC 1045                       VMTP                        February 1988 
  4447.  
  4448.  
  4449. |       if lastcsr not completed then
  4450. |           NotifyClient( lastcsr, p, RETRY )
  4451. |       endif
  4452. |       if lastcsr available then use it for this packet group
  4453. |       else allocate and initialize new CSR
  4454. |       if CMG(lastcsr) then
  4455. |          Add segment data to lastcsr Request
  4456. |          Keep csr as record of this packet group.
  4457. |          Clear lastcsr.VerifyInterval
  4458. |      endif
  4459. |   else { First packet group }
  4460.         if MultipleRemoteClients(csr) then ScavengeCsrs(p.Client)
  4461.         Set csr.RemoteTransaction, csr.Priority
  4462.         Copy message and segment data to csr's segment area
  4463.          and set csr.PacketDelivery to that delivered.
  4464.         Clear csr.PacketDelivery
  4465.         Clear csr.VerifyInterval
  4466.         SaveNetworkAddress( csr, p )
  4467.     endif
  4468.     if packetgroup not complete then
  4469.         Timeout( csr, TS3(p.Client), RemoteClientTimeout )
  4470.         return;
  4471.     endif
  4472. endPacketGroup:
  4473.     { We have received complete packet group. }
  4474.     if APG(p) then NotifyClient( csr, p, OK )
  4475.     endif
  4476. |   if NERset(p) and CMG(p) then
  4477. |       Queue waiting for continuation packet group.
  4478. |       Timeout( csr, TS3(csr.Client), RemoteClientTimeout )
  4479. |       return
  4480. |   endif
  4481.     { Deliver request message. }
  4482.     if GroupId(csr.Server) then
  4483.         For each server identified by csr.Server
  4484.             Replicate csr and associated data segment.
  4485.             if CMDset(csr) and Server busy then
  4486.                Discard csr and data
  4487.             else
  4488.                Deliver or invoke csr for each Server.
  4489.             if not DGMset(csr) then queue for Response
  4490.             else Timeout( csr, TS4(csr.Client), FreeCsr )
  4491.         endfor
  4492.      else
  4493.        if CMDset(csr) and Server busy then
  4494.            Discard csr and data
  4495.         else
  4496.  
  4497.  
  4498. Cheriton                                                       [page 76]
  4499.  
  4500.  
  4501.  
  4502. RFC 1045                       VMTP                        February 1988 
  4503.  
  4504.  
  4505.            Deliver or invoke csr for this server.
  4506.         if not DGMset(csr) then queue for Response
  4507.         else Timeout( csr, TS4(csr.Client), FreeCsr )
  4508.      endif
  4509. end HandleRequest
  4510.  
  4511. Notes:
  4512.  
  4513.    1. A Request received that specifies a Client that is a local
  4514.       entity should be a Request forwarded by a remote server to a
  4515.       local Server.
  4516.  
  4517.    2. An alternative structure for handling a Request sent to a
  4518.       group when there are multiple local group members is to
  4519.       create a remote CSR for each group member on reception of the
  4520.       first packet and deliver a copy of each packet to each such
  4521.       remote CSR as each packet arrives.
  4522.  
  4523.  
  4524.  
  4525.  
  4526.  
  4527.  
  4528.  
  4529.  
  4530.  
  4531.  
  4532.  
  4533.  
  4534.  
  4535.  
  4536.  
  4537.  
  4538.  
  4539.  
  4540.  
  4541.  
  4542.  
  4543.  
  4544.  
  4545.  
  4546.  
  4547.  
  4548.  
  4549.  
  4550.  
  4551.  
  4552.  
  4553.  
  4554. Cheriton                                                       [page 77]
  4555.  
  4556.  
  4557.  
  4558. RFC 1045                       VMTP                        February 1988 
  4559.  
  4560.  
  4561. 5.8. Management Operations
  4562.  
  4563. VMTP uses management operations (invoked as remote procedure calls) to
  4564. effectively acknowledge packet groups and request retransmissions.  The
  4565. following routine is invoked by the Server's management module on
  4566. request from the Client.
  4567.  
  4568. NotifyVmtpServer(server,clientId,transact,delivery,code)
  4569.     Find csr with same RemoteTransaction and RemoteClient
  4570.     as clientId and transact.
  4571.     if not found or csr.State not Responded then return
  4572.     if DGMset(csr) then
  4573.         if transmission of Response in progress then
  4574.             Abort transmission
  4575.             if code is migrated then
  4576.                restart transmission with new host addr.
  4577.         if Retry then Report protocol error
  4578.         return
  4579.     endif
  4580.     select on code
  4581.       case RETRY:
  4582.         if csr.RetransCount > MaxRetrans(clientId) then
  4583.              if response data segment then
  4584.                  Discard data and mark as RESPONSE_DISCARDED
  4585. |                if NERset(csr) and subsequent csr then
  4586. |                    Deallocate csr and use later csr for
  4587. |                    future duplicate suppression
  4588. |                endif
  4589.              return
  4590.         endif
  4591.         increment csr.RetransCount
  4592.         Set csr.TransmissionMask to missing segment blocks,
  4593.             as specified by delivery
  4594.         SendPacketGroup( csr )
  4595.         Timeout( csr, TS3(csr.Client), RemoteClientTimeout )
  4596.       case BUSY:
  4597.         if csr.TimeLimit exceeded then
  4598.             if response data segment then
  4599.                 Discard data and mark as RESPONSE_DISCARDED
  4600. |               if NERset(csr) and subsequent csr then
  4601. |                   Deallocate csr and use later csr for
  4602. |                   future duplicate suppression
  4603. |               endif
  4604.              endif
  4605.         endif
  4606.         Set csr.TransmissionMask for full retransmission
  4607.         Clear csr.RetransCount
  4608.  
  4609.  
  4610. Cheriton                                                       [page 78]
  4611.  
  4612.  
  4613.  
  4614. RFC 1045                       VMTP                        February 1988 
  4615.  
  4616.  
  4617.         Timeout( csr, TS3(csr.Server), RemoteClientTimeout )
  4618.         return
  4619.  
  4620.       case ENTITY_MIGRATED:
  4621.         Get new host address for entity
  4622.         Set csr.TransmissionMask for full retransmission
  4623.         Clear csr.RetransCount
  4624.         SendPacketGroup( csr )
  4625.         Timeout( csr, TS3(csr.Server), RemoteClientTimeout )
  4626.         return
  4627.  
  4628.       case default:
  4629.         Abort transmission of Response if in progress.
  4630.         if response data segment then
  4631.            Discard data and mark as RESPONSE_DISCARDED
  4632.            if NERset(csr) and subsequent csr then
  4633.                Deallocate csr and use later csr for
  4634.                future duplicate suppression
  4635.            endif
  4636.         return
  4637.     endselect
  4638. end NotifyVmtpServer
  4639.  
  4640. Notes:
  4641.  
  4642.    1. A NotifyVmtpServer operation requesting retransmission of
  4643.       the Response is acceptable only if the Response was not
  4644.       idempotent.  When the Response is idempotent, the Client must
  4645.       be prepared to retransmit the Request to effectively request
  4646.       retransmission of the Response.
  4647.  
  4648.    2. A NotifyVmtpServer operation may be received while the
  4649.       Response is being transmitted.  If an error return, as an
  4650.       efficiency, the transmission should be aborted, as suggested
  4651.       when the Response is a datagram.
  4652.  
  4653.    3. A NotifyVmtpServer operation indicating OK or an error
  4654.       allows the Server to discard segment data and not provide for
  4655.       subsequent retransmission of the Response.
  4656.  
  4657.  
  4658. 5.8.1. HandleRequestNoCSR
  4659.  
  4660. When a Request is received from a Client for which the node has no CSR,
  4661. the node allocates and initializes a CSR for this Client and does a
  4662. callback to the Client's VMTP management module to get the Principal,
  4663. Process and other information associated with this Client.  It also
  4664.  
  4665.  
  4666. Cheriton                                                       [page 79]
  4667.  
  4668.  
  4669.  
  4670. RFC 1045                       VMTP                        February 1988 
  4671.  
  4672.  
  4673. checks that the TransactionId is correct in order to filter out
  4674. duplicates.
  4675.  
  4676. HandleRequestNoCSR( p, psize )
  4677. |   if Secure(p) then
  4678. |       Allocate and init CSR
  4679. |       SaveSourceHostAddr( csr, p )
  4680. |       ProbeRemoteClient( csr, p, AUTH_PROBE )
  4681. |       if no response or error then
  4682. |          delete CSR
  4683. |          return
  4684. |       Decrypt( csr.Key, p, psize )
  4685. |        if p.Checksum not null then
  4686. |       if not VerifyChecksum(p, psize) then return;
  4687. |       if OppositeByteOrder(p) then ByteSwap( p, psize )
  4688. |       if psize not equal sizeof(VmtpHeader) + 4*p.Length then
  4689. |          NotifyClient(NULL, p, VMTP_ERROR )
  4690. |          return
  4691. |       HandleRequest( csr, p, psize )
  4692. |       return
  4693.     if Server does not exist then
  4694.         NotifyClient( csr, p, NONEXISTENT_ENTITY )
  4695.         return
  4696.     endif
  4697.     if security required by server then
  4698.         NotifyClient(csr, p, SECURITY_REQUIRED )
  4699.         return
  4700.     endif
  4701.     Allocate and init CSR
  4702.     SaveSourceHostAddr( csr, p );
  4703.     if server requires Authentication then
  4704.         ProbeRemoteClient( csr, p, AUTH_PROBE )
  4705.         if no response or error then
  4706.            delete CSR
  4707.            return
  4708.     endif
  4709.     { Setup immediately as a new message transaction }
  4710.     set csr.Server to p.Server
  4711.     set csr.RemoteTransaction to p.Transaction-1
  4712.  
  4713.     HandleRequest( csr, p, psize )
  4714.     endif
  4715.  
  4716. Notes:
  4717.  
  4718.    1. A Probe request is always handled as a Request not requiring
  4719.       authentication so it never generates a callback Probe to the
  4720.  
  4721.  
  4722. Cheriton                                                       [page 80]
  4723.  
  4724.  
  4725.  
  4726. RFC 1045                       VMTP                        February 1988 
  4727.  
  4728.  
  4729.       Client.
  4730.  
  4731.    2. If the Server host retains remote client CSR's for longer
  4732.       than the maximum packet lifetime and the Request
  4733.       retransmission time, and the host has been running for at
  4734.       least that long, then it is not necessary to do a Probe
  4735.       callback unless the Request is secure.  A Probe callback can
  4736.       take place when the Server asks for the Process or
  4737.       PrincipalId associated with the Client.
  4738.  
  4739.  
  4740.  
  4741.  
  4742.  
  4743.  
  4744.  
  4745.  
  4746.  
  4747.  
  4748.  
  4749.  
  4750.  
  4751.  
  4752.  
  4753.  
  4754.  
  4755.  
  4756.  
  4757.  
  4758.  
  4759.  
  4760.  
  4761.  
  4762.  
  4763.  
  4764.  
  4765.  
  4766.  
  4767.  
  4768.  
  4769.  
  4770.  
  4771.  
  4772.  
  4773.  
  4774.  
  4775.  
  4776.  
  4777.  
  4778. Cheriton                                                       [page 81]
  4779.  
  4780.  
  4781.  
  4782. RFC 1045                       VMTP                        February 1988 
  4783.  
  4784.  
  4785. 5.9. Timeouts
  4786.  
  4787. The server must implement a timeout for remote client CSRs.  There is a
  4788. timeout for each CSR in the server.
  4789.  
  4790. RemoteClientTimeout( csr )
  4791.   select on csr.State
  4792.     case Responded:
  4793.         if RESPONSE_DISCARDED then
  4794.             mark as timed out
  4795.             Make a candidate for reuse.
  4796.             return
  4797.         if csr.RetransCount > MaxRetrans(Client) then
  4798.             discard Response
  4799.             mark CSR as RESPONSE_DISCARDED
  4800.             Timeout(csr, TS4(Client), RemoteClientTimeout)
  4801.             return
  4802.         increment csr.RetransCount
  4803.         { Retransmit Response or forwarded Request }
  4804.         Set APG to get acknowledgement.
  4805.         SendPacketGroup( csr )
  4806.         Timeout( csr, TS3(Client), RemoteClientTimeout )
  4807.         return
  4808.     case ReceivingRequest:
  4809.       if csr.RetransCount > MaxRetrans(csr.Client)
  4810.          or DGMset(csr) or NRTset(csr) then
  4811.           Modify csr.segmentSize and csr.MsgDelivery
  4812.           to indicate packets received.
  4813.           if MDMset(csr) then
  4814.               Invoke processing on Request
  4815.               return
  4816.           else
  4817.               discard Request and reuse CSR
  4818.               (Note: Need not remember Request discarded.)
  4819.               return
  4820.       increment csr.RetransCount
  4821.       NotifyClient( csr, p, RETRY )
  4822.       Timeout( csr, TS3(Client), RemoteClientTimeout )
  4823.       return
  4824.     default:
  4825.         Report error - invalid state for RemoteClientTimeout
  4826.     endselect
  4827. end RemoteClientTimeout
  4828.  
  4829. Notes:
  4830.  
  4831.    1. When a CSR in the Responded state times out after discarding
  4832.  
  4833.  
  4834. Cheriton                                                       [page 82]
  4835.  
  4836.  
  4837.  
  4838. RFC 1045                       VMTP                        February 1988 
  4839.  
  4840.  
  4841.       the Response, it can be made available for reuse, either by
  4842.       the same Client or a different one.  The CSR should be kept
  4843.       available for reuse by the Client for as long as possible to
  4844.       avoid unnecessary callback Probes.
  4845.  
  4846.  
  4847.  
  4848.  
  4849.  
  4850.  
  4851.  
  4852.  
  4853.  
  4854.  
  4855.  
  4856.  
  4857.  
  4858.  
  4859.  
  4860.  
  4861.  
  4862.  
  4863.  
  4864.  
  4865.  
  4866.  
  4867.  
  4868.  
  4869.  
  4870.  
  4871.  
  4872.  
  4873.  
  4874.  
  4875.  
  4876.  
  4877.  
  4878.  
  4879.  
  4880.  
  4881.  
  4882.  
  4883.  
  4884.  
  4885.  
  4886.  
  4887.  
  4888.  
  4889.  
  4890. Cheriton                                                       [page 83]
  4891.  
  4892.  
  4893.  
  4894. RFC 1045                       VMTP                        February 1988 
  4895.  
  4896.  
  4897. 6. Concluding Remarks
  4898.  
  4899. This document represents a description of the current state of the VMTP
  4900. design.  We are currently engaged in several experimental
  4901. implementations to explore and refine all aspects of the protocol.
  4902. Preliminary implementations are running in the UNIX 4.3BSD kernel and in
  4903. the V kernel.
  4904.  
  4905. Several issues are still being discussed and explored with this
  4906. protocol.  First, the size of the checksum field and the algorithm to
  4907. use for its calculation are undergoing some discussion.  The author
  4908. believes that the conventional 16-bit checksum used with TCP and IP is
  4909. too weak for future high-speed networks, arguing for at least a 32-bit
  4910. checksum.  Unfortunately, there appears to be limited theory covering
  4911. checksum algorithms that are suitable for calculation in software.
  4912.  
  4913. Implementation of the streaming facilities of VMTP is still in progress.
  4914. This facility is expected to be important for wide-area, long delay
  4915. communication.
  4916.  
  4917.  
  4918.  
  4919.  
  4920.  
  4921.  
  4922.  
  4923.  
  4924.  
  4925.  
  4926.  
  4927.  
  4928.  
  4929.  
  4930.  
  4931.  
  4932.  
  4933.  
  4934.  
  4935.  
  4936.  
  4937.  
  4938.  
  4939.  
  4940.  
  4941.  
  4942.  
  4943.  
  4944.  
  4945.  
  4946. Cheriton                                                       [page 84]
  4947.  
  4948.  
  4949.  
  4950. RFC 1045                       VMTP                        February 1988 
  4951.  
  4952.  
  4953. I. Standard VMTP Response Codes
  4954.  
  4955. The following are the numeric values of the response codes used in VMTP.
  4956.  
  4957. 0               OK
  4958.  
  4959. 1               RETRY
  4960.  
  4961. 2               RETRY_ALL
  4962.  
  4963. 3               BUSY
  4964.  
  4965. 4               NONEXISTENT_ENTITY
  4966.  
  4967. 5               ENTITY_MIGRATED
  4968.  
  4969. 6               NO_PERMISSION
  4970.  
  4971. 7               NOT_AWAITING_MSG
  4972.  
  4973. 8               VMTP_ERROR
  4974.  
  4975. 9               MSGTRANS_OVERFLOW
  4976.  
  4977. 10              BAD_TRANSACTION_ID
  4978.  
  4979. 11              STREAMING_NOT_SUPPORTED
  4980.  
  4981. 12              NO_RUN_RECORD
  4982.  
  4983. 13              RETRANS_TIMEOUT
  4984.  
  4985. 14              USER_TIMEOUT
  4986.  
  4987. 15              RESPONSE_DISCARDED
  4988.  
  4989. 16              SECURITY_NOT_SUPPORTED
  4990.  
  4991. 17              BAD_REPLY_SEGMENT
  4992.  
  4993. 18              SECURITY_REQUIRED
  4994.  
  4995. 19              STREAMED_RESPONSE
  4996.  
  4997. 20              TOO_MANY_RETRIES
  4998.  
  4999. 21              NO_PRINCIPAL
  5000.  
  5001.  
  5002. Cheriton                                                       [page 85]
  5003.  
  5004.  
  5005.  
  5006. RFC 1045                       VMTP                        February 1988 
  5007.  
  5008.  
  5009. 22              NO_KEY
  5010.  
  5011. 23              ENCRYPTION_NOT_SUPPORTED
  5012.  
  5013. 24              NO_AUTHENTICATOR
  5014.  
  5015. 25-63           Reserved for future VMTP assignment.
  5016.  
  5017. Other values of the codes are available for use by higher level
  5018. protocols.  Separate protocol documents will specify further standard
  5019. values.
  5020.  
  5021. Applications are free to use values starting at 0x00800000 (hex) for
  5022. application-specific return values.
  5023.  
  5024.  
  5025.  
  5026.  
  5027.  
  5028.  
  5029.  
  5030.  
  5031.  
  5032.  
  5033.  
  5034.  
  5035.  
  5036.  
  5037.  
  5038.  
  5039.  
  5040.  
  5041.  
  5042.  
  5043.  
  5044.  
  5045.  
  5046.  
  5047.  
  5048.  
  5049.  
  5050.  
  5051.  
  5052.  
  5053.  
  5054.  
  5055.  
  5056.  
  5057.  
  5058. Cheriton                                                       [page 86]
  5059.  
  5060.  
  5061.  
  5062. RFC 1045                       VMTP                        February 1988 
  5063.  
  5064.  
  5065. II. VMTP RPC Presentation Protocol
  5066.  
  5067. For complete generality, the mapping of the procedures and the
  5068. parameters onto VMTP messages should be defined by a RPC presentation
  5069. protocol.  In the absence of an accepted standard protocol, we define an
  5070. RPC presentation protocol for VMTP as follows.
  5071.  
  5072. Each procedure is assigned an identifying Request Code.  The Request
  5073. code serves effectively the same as a tag field of variant record,
  5074. identifying the format of the Request and associated Response as a
  5075. variant of the possible message formats.
  5076.  
  5077. The format of the Request for a procedure is its Request Code followed
  5078. by its parameters sequentially in the message control block until it is
  5079. full.
  5080.  
  5081. The remaining parameters are sent as part of the message segment data
  5082. formatted according to the XDR protocol (RFC ??).  In this case, the
  5083. size of the segment is specified in the SegmentSize field.
  5084.  
  5085. The Response for a procedure consists of a ResponseCode field followed
  5086. by the return parameters sequentially in the message control block,
  5087. except if there is a parameter returned that must be transmitted as
  5088. segment data, its size is specified in the SegmentSize field and the
  5089. parameter is stored in the SegmentData field.
  5090.  
  5091. Attributes associated with procedure definitions should indicate the
  5092. Flags to be used in the RequestCode.  Request Codes are assigned as
  5093. described below.
  5094.  
  5095.  
  5096. II.1. Request Code Management
  5097.  
  5098. Request codes are divided into Public Interface Codes and
  5099. application-specific, according to whether the PIC value is set.  An
  5100. interface is a set of request codes representing one service or module
  5101. function.  A public interface is one that is to be used in multiple
  5102. independently developed modules.  In VMTP, public interface codes are
  5103. allocated in units of 256 structured as
  5104.  
  5105.  +-------------+----------------+-------------------+
  5106.  | ControlFlags|  Interface     | Version/Procedure |
  5107.  +-------------+----------------+-------------------+
  5108.     8 bits          16 bits              8 bits
  5109.  
  5110. An interface is free to allocate the 8 bits for version and procedure as
  5111. desired.  For example, all 8 bits can be used for procedures.  A module
  5112. requiring more than 256 Version/Procedure values can be allocated
  5113.  
  5114. Cheriton                                                       [page 87]
  5115.  
  5116.  
  5117.  
  5118. RFC 1045                       VMTP                        February 1988 
  5119.  
  5120.  
  5121. multiple Interface values.  They need not be consecutive Interface
  5122. values.
  5123.  
  5124.  
  5125.  
  5126.  
  5127.  
  5128.  
  5129.  
  5130.  
  5131.  
  5132.  
  5133.  
  5134.  
  5135.  
  5136.  
  5137.  
  5138.  
  5139.  
  5140.  
  5141.  
  5142.  
  5143.  
  5144.  
  5145.  
  5146.  
  5147.  
  5148.  
  5149.  
  5150.  
  5151.  
  5152.  
  5153.  
  5154.  
  5155.  
  5156.  
  5157.  
  5158.  
  5159.  
  5160.  
  5161.  
  5162.  
  5163.  
  5164.  
  5165.  
  5166.  
  5167.  
  5168.  
  5169.  
  5170. Cheriton                                                       [page 88]
  5171.  
  5172.  
  5173.  
  5174. RFC 1045                       VMTP                        February 1988 
  5175.  
  5176.  
  5177. III. VMTP Management Procedures
  5178.  
  5179. Standard procedures are defined for VMTP management, including creation,
  5180. deletion and query of entities and entity groups, probing to get
  5181. information about entities, and updating message transaction information
  5182. at the client or the server.
  5183.  
  5184. The procedures are implemented by the VMTP manager that constitutes a
  5185. portion of every complete VMTP module.  Each procedure is invoked by
  5186. sending a Request to the VMTP manager that handles the entity specified
  5187. in the operation or the local manager.  The Request sent using the
  5188. normal Send operation with the Server specified as the well-known entity
  5189. group VMTP_MANGER_GROUP, using the CoResident Entity mechanism to direct
  5190. the request to the specific manager that should handle the Request.
  5191. (The ProbeEntity operation is multicast to the VMTP_MANAGER_GROUP if the
  5192. host address for the entity is not known locally and the host address is
  5193. determined as the host address of the responder.  For all other
  5194. operations, a ProbeEntity operation is used to determine the host
  5195. address if it is not known.)  Specifying co-resident entity 0 is
  5196. interpreted as the co-resident with the invoking process.  The
  5197. co-resident entity identifier may also specify a group in which case,
  5198. the Request is sent to all managers with members in this group.
  5199.  
  5200. The standard procedures with their RequestCode and parameters are listed
  5201. below with their semantics.  (The RequestCode range 0xVV000100 to
  5202. 0xVV0001FF is reserved for use by the VMTP management routines, where VV
  5203. is any choice of control flags with the PIC bit set.  The flags are set
  5204. below as required for each procedure.)
  5205.  
  5206. 0x05000101 - ProbeEntity(CREntity, entityId, authDomain) -> (code,
  5207.                 <staterec>) 
  5208.                 Request and return information on the specified entity
  5209.                 in the specified authDomain, sending the Request to the
  5210.                 VMTP management module coresident with CREntity.  An
  5211.                 error return is given if the requested information
  5212.                 cannot be provided in the specified authDomain.  The
  5213.                 <staterec> returned is structured as the following
  5214.                 fields.
  5215.  
  5216.                 Transaction identifier
  5217.                                 The current or next transaction
  5218.                                 identifier being used by the probed
  5219.                                 entity.
  5220.  
  5221.                 ProcessId: 64 bits 
  5222.                                 Identifier for client process.  The
  5223.                                 meaning of this is specified as part of
  5224.  
  5225.  
  5226. Cheriton                                                       [page 89]
  5227.  
  5228.  
  5229.  
  5230. RFC 1045                       VMTP                        February 1988 
  5231.  
  5232.  
  5233.                                 the Domain definition.
  5234.  
  5235.                 PrincipalId     The identifier for the principal or
  5236.                                 account associated with the process
  5237.                                 specified by ProcessId.  The meaning of
  5238.                                 this field is specified as part of the
  5239.                                 Domain definition.
  5240.  
  5241.                 EffectivePrincipalId
  5242.                                 The identifier for the principal or
  5243.                                 account associated with the Client port,
  5244.                                 which may be different from the
  5245.                                 PrincipalId especially if this is an
  5246.                                 nested call.  The meaning of this field
  5247.                                 is specified as part of the Domain
  5248.                                 definition.
  5249.  
  5250.                 The code field indicates whether this is an error
  5251.                 response or not.  The codes and their interpretation
  5252.                 are:
  5253.  
  5254.                   OK
  5255.                 No error. Probe was completed OK.
  5256.  
  5257.                   NONEXISTENT_ENTITY
  5258.                 Specified entity does not exist.
  5259.  
  5260.                   ENTITY_MIGRATED
  5261.                 The entity has migrated and is no longer at the host to
  5262.                 which the request was sent.
  5263.  
  5264.                   NO_PERMISSION
  5265.                 Entity has refused to provide ProbeResponse.
  5266.  
  5267.                   VMTP_ERROR
  5268.                 The Request packet group was in error relative to the
  5269.                 VMTP protocol specification.
  5270.  
  5271.                   "default"
  5272.                 Some type of error - discard ProbeResponse.
  5273.  
  5274. 0x0D000102 - AuthProbeEntity(CREntity,entityId,authDomain,randomId) ->
  5275.                 (code,ProbeAuthenticator,EncryptType,EntityAuthenticator)
  5276.                 
  5277.                 Request authentication of the entity specified by
  5278.                 entityId from the VMTP manager coresident with CREntity
  5279.                 in authDomain authentication domain, returning the
  5280.  
  5281.  
  5282. Cheriton                                                       [page 90]
  5283.  
  5284.  
  5285.  
  5286. RFC 1045                       VMTP                        February 1988 
  5287.  
  5288.  
  5289.                 information contained in the return parameters.  The
  5290.                 fields are set the same as that specified for the basic
  5291.                 ProbeResponse except as noted below.
  5292.  
  5293.                 ProbeAuthenticator
  5294.                                 20 bytes consisting of the EntityId, the
  5295.                                 randomId and the probed Entity's current
  5296.                                 Transaction value plus a 32-bit checksum
  5297.                                 for these two fields (checksummed using
  5298.                                 the standard packet Checksum algorithm),
  5299.                                 all encrypted with the Key supplied in
  5300.                                 the Authenticator.
  5301.  
  5302.                 EncryptType     An identifier that identifies the
  5303.                                 variant of encryption method being used
  5304.                                 by the probed Entity for packets it
  5305.                                 transmits and packets it is able to
  5306.                                 receive.  (See Appendix V.)  The
  5307.                                 high-order 8 bits of the EncryptType
  5308.                                 contain the XOR of the 8 octets of the
  5309.                                 PrincipalId associated with private key
  5310.                                 used to encrypt the EntityAuthenticator.
  5311.                                 This value is used by the requestor or
  5312.                                 Client as an aid in locating the key to
  5313.                                 decrypt the authenticator.
  5314.  
  5315.                 EntityAuthenticator
  5316.                                 (returned as segment data) The
  5317.                                 ProcessId, PrincipalId,
  5318.                                 EffectivePrincipal associated with the
  5319.                                 ProbedEntity plus the private
  5320.                                 encryption/decryption key and its
  5321.                                 lifetime limit to be used for
  5322.                                 communication with the Entity.  The
  5323.                                 authenticator is encrypted with a
  5324.                                 private key associated with the Client
  5325.                                 entity such that it can be neither read
  5326.                                 nor forged by a party not trusted by the
  5327.                                 Client Entity.  The format of the
  5328.                                 Authenticator in the message segment is
  5329.                                 shown in detail in Figure III-1.
  5330.  
  5331.                 Key: 64 bits    Encryption key to be used for encrypting
  5332.                                 and decrypting packets sent to and
  5333.                                 received from the probed Entity.  This
  5334.                                 is the "working" key for packet
  5335.                                 transmissions.  VMTP only uses private
  5336.  
  5337.  
  5338. Cheriton                                                       [page 91]
  5339.  
  5340.  
  5341.  
  5342. RFC 1045                       VMTP                        February 1988 
  5343.  
  5344.  
  5345.                 +-----------------------------------------------+
  5346.                 |            ProcessId   (8 octets)             |
  5347.                 +-----------------------------------------------+
  5348.                 |           PrincipalId  (8 octets)             |
  5349.                 +-----------------------------------------------+
  5350.                 |           EffectivePrincipalId  (8 octets)    |
  5351.                 +-----------------------------------------------+
  5352.                 |            Key  (8 octets)                    |
  5353.                 +-----------------------------------------------+
  5354.                 |              KeyTimeLimit                     |
  5355.                 +-----------------------------------------------+
  5356.                 |              AuthDomain                       |
  5357.                 +-----------------------------------------------+
  5358.                 |               AuthChecksum                    |
  5359.                 +-----------------------------------------------+
  5360.  
  5361.                   Figure III-1:   Authenticator Format
  5362.  
  5363.                                 key encryption for data transmission.
  5364.  
  5365.                 KeyTimeLimit: 32 bits 
  5366.                                 The time in seconds since Dec. 31st,
  5367.                                 1969 GMT at which one should cease to
  5368.                                 use the Key.
  5369.  
  5370.                 AuthDomain: 32 bits 
  5371.                                 The authentication domain in which to
  5372.                                 interpret the principal identifiers.
  5373.                                 This may be different from the
  5374.                                 authDomain specified in the call if the
  5375.                                 Server cannot provide the authentication
  5376.                                 information in the request domain.
  5377.  
  5378.                 AuthChecksum: 32 bits 
  5379.                                 Contains the checksum (using the same
  5380.                                 Checksum algorithm as for packet) of
  5381.                                 KeyTimeLimit, Key, PrincipalId and
  5382.                                 EffectivePrincipalId.
  5383.  
  5384.                 Notes:
  5385.  
  5386.                    1. A authentication Probe Request and Response
  5387.                       are sent unencrypted in general because it is
  5388.                       used prior to there being a secure channel.
  5389.                       Therefore, specific fields or groups of
  5390.                       fields checksummed and encrypted to prevent
  5391.                       unauthorized modification or forgery.  In
  5392.  
  5393.  
  5394. Cheriton                                                       [page 92]
  5395.  
  5396.  
  5397.  
  5398. RFC 1045                       VMTP                        February 1988 
  5399.  
  5400.  
  5401.                       particular, the ProbeAuthenticator is
  5402.                       checksummed and encrypted with the Key.
  5403.  
  5404.                    2. The ProbeAuthenticator authenticates the
  5405.                       Response as responding to the Request when
  5406.                       its EntityId, randomId and Transaction values
  5407.                       match those in the Probe request.  The
  5408.                       ProbeAutenticator is bound to the
  5409.                       EntityAutenticator by being encrypted by the
  5410.                       private Key contained in that authenticator.
  5411.  
  5412.                    3. The authenticator is encrypted such that it
  5413.                       can be decrypted by a private key, known to
  5414.                       the Client.  This authenticator is presumably
  5415.                       obtained from a key distribution center that
  5416.                       the Client trusts.  The AuthChecksum prevents
  5417.                       undetected modifications to the
  5418.                       authenticator.
  5419.  
  5420. 0x05000103 - ProbeEntityBlock( entityId ) -> ( code, entityId ) 
  5421.                 Check whether the block of 256 entity identifiers
  5422.                 associated with this entityId are in use.  The entityId
  5423.                 returned should match that being queried or else the
  5424.                 return value should be ignored and the operation redone.
  5425.  
  5426. 0x05000104 - QueryVMTPNode( entityId ) -> (code, MTU, flags, authdomain,
  5427.                 domains, authdomains, domainlist) 
  5428.                 Query the VMTP management module for entityId to get
  5429.                 various module- or node-wide parameters, including:  (1)
  5430.                 MTU - Maximum transmission unit or packet size handled
  5431.                 by this node.  (2) flags- zero or more of the following
  5432.                 bit fields:
  5433.  
  5434.                 1               Handles streamed Requests.
  5435.  
  5436.                 2               Can issue streamed message transactions
  5437.                                 for clients.
  5438.  
  5439.                 4               Handles secure Requests.
  5440.  
  5441.                 8               Can issue secure message transactions.
  5442.  
  5443.                 The authdomain indicates the primary authentication
  5444.                 domain supported.  The domains and authdomains
  5445.                 parameters indicate the number of entity domains and
  5446.                 authentication domains supported by this node, which are
  5447.                 listed in the data segment parameter domainlist if
  5448.  
  5449.  
  5450. Cheriton                                                       [page 93]
  5451.  
  5452.  
  5453.  
  5454. RFC 1045                       VMTP                        February 1988 
  5455.  
  5456.  
  5457.                 either parameter is non-zero. (All the entity domains
  5458.                 precede the authentication domains in the data segment.)
  5459.  
  5460. 0x05000105 - GetRequestForwarder( CREntity, entityId1 ) -> (code,
  5461.                 entityId2, principal, authDomain) 
  5462.                 Return the forwarding server's entity identifer and
  5463.                 principal for the forwarder of entityId1.  CREntity
  5464.                 should be zero to get the local VMTP management module.
  5465.  
  5466. 0x05000106 - CreateEntity( entityId1 ) -> ( code, entityId2 ) 
  5467.                 Create a new entity and return its entity identifier in
  5468.                 entityId2.  The entity is created local to the entity
  5469.                 specified in entityId1 and local to the requestor if
  5470.                 entityId1 is 0.
  5471.  
  5472. 0x05000107 - DeleteEntity( entityId ) -> ( code ) 
  5473.                 Delete the entity specified by entityId, which may be a
  5474.                 group.  If a group, the deletion is only on a best
  5475.                 efforts basis.  The client must take additional measures
  5476.                 to ensure complete deletion if required.
  5477.  
  5478. 0x0D000108 -QueryEntity( entityId ) -> ( code, descriptor ) 
  5479.                 Return a descriptor of entityId in arg of a maximum of
  5480.                 segmentSize bytes.
  5481.  
  5482. 0x05000109 - SignalEntity( entityId, arg )->( code ) 
  5483.                 Send the signal specified by arg to the entity specified
  5484.                 by entityId.  (arg is 32 bits.)
  5485.  
  5486. 0x0500010A - CreateGroup(CREntity,entityGroupId,entityId,perms)->(code)
  5487.                 Request that the VMTP manager local to CREntity create
  5488.                 an new entity group, using the specified entityGroupId
  5489.                 with entityId as the first member and permissions
  5490.                 "perms", a 32-bit field described later.  The invoker is
  5491.                 registered as a manager of the new group, giving it the
  5492.                 permissions to add or remove members.  (Normally
  5493.                 CREntity is 0, indicating the VMTP manager local to the
  5494.                 requestor.)
  5495.  
  5496. 0x0500010B - AddToGroup(CREntity, entityGroupId, entityId,
  5497.                 perms)->(code) 
  5498.                 Request that the VMTP manager local to CREntity add the
  5499.                 specified entityId to the entityGroupId with the
  5500.                 specified permissions.  If entityGroupId specifies a
  5501.                 restricted group, the invoker must have permission to
  5502.                 add members to the group, either because the invoker is
  5503.  
  5504.  
  5505. Cheriton                                                       [page 94]
  5506.  
  5507.  
  5508.  
  5509. RFC 1045                       VMTP                        February 1988 
  5510.  
  5511.  
  5512.                 a manager of the group or because it was added to the
  5513.                 group with the required permissions.  If CREntity is 0,
  5514.                 then the local VMTP manager checks permissions and
  5515.                 forwards the request with CREntity set to entityId and
  5516.                 the entityId field set to a digital signature (see
  5517.                 below) of the Request by the VMTP manager, certifying
  5518.                 that the Client has the permissions required by the
  5519.                 Request.  (If entityGroupId specifies an unrestricted
  5520.                 group, the Request can be sent directly to the handling
  5521.                 VMTP manager by setting CREntity to entityId.)
  5522.  
  5523. 0x0500010C - RemoveFromGroup(CREntity, entityGroupId, entityId)->(code) 
  5524.                 Request that the VMTP manager local to CREntity remove
  5525.                 the specified entityId from the group specified by
  5526.                 entityGroupId.  Normally CREntity is 0, indicating the
  5527.                 VMTP manager local to the requestor.  If CREntity is 0,
  5528.                 then the local VMTP manager checks permissions and
  5529.                 forwards the request with CREntity set to entityId and
  5530.                 the entityId field a digital signature of the Request by
  5531.                 the VMTP manager, certifying that the Client has the
  5532.                 permissions required by the Request.
  5533.  
  5534. 0x0500010D - QueryGroup( entityId )->( code, record )...  
  5535.                 Return information on the specified entity.  The
  5536.                 Response from each responding VMTP manager is (code,
  5537.                 record).  The format of the record is (memberCount,
  5538.                 member1, member2, ...).  The Responses are returned on a
  5539.                 best efforts basis; there is no guarantee that responses
  5540.                 from all managers with members in the specified group
  5541.                 will be received.
  5542.  
  5543. 0x0500010E - ModifyService(entityId,flags,count,pc,threadlist)->(code,
  5544.                 count) 
  5545.                 Modify the service associated with the entity specified
  5546.                 by entityId.  The flags may indicate a message service
  5547.                 model, in which case the call "count" parameter
  5548.                 indicates the maximum number of queued messages desired;
  5549.                 the return "count" parameter indicates the number of
  5550.                 queued message allowed.  Alternatively, the "flags"
  5551.                 parameters indicates the RPC thread service model, in
  5552.                 which case "count" threads are requested, each with an
  5553.                 inital program counter as specified and stack, priority
  5554.                 and message receive area indicated by the threadlist.
  5555.                 In particular, "threadlist" consists of "count" records
  5556.                 of the form
  5557.                 (priority,stack,stacksize,segment,segmentsize), each one
  5558.                 assigned to one of the threads.  Flags defined for the
  5559.  
  5560.  
  5561. Cheriton                                                       [page 95]
  5562.  
  5563.  
  5564.  
  5565. RFC 1045                       VMTP                        February 1988 
  5566.  
  5567.  
  5568.                 "flags" parameter are:
  5569.  
  5570.                 1               THREAD_SERVICE - otherwise the message
  5571.                                 model.
  5572.  
  5573.                 2               AUTHENTICATION_REQUIRED - Sent a Probe
  5574.                                 request to determine principal
  5575.                                 associated with the Client, if not
  5576.                                 known.
  5577.  
  5578.                 4               SECURITY_REQUIRED - Request must be
  5579.                                 encrypted or else reject.
  5580.  
  5581.                 8               INCREMENTAL - treat the count value as
  5582.                                 an increment (or decrement) relative to
  5583.                                 the current value rather than an
  5584.                                 absolute value for the maximum number of
  5585.                                 queued messages or threads.
  5586.  
  5587.                 In the thread model, the count must be a positive
  5588.                 increment or else 0, which disables the service.  Only a
  5589.                 count of 0 terminates currently queued requests or
  5590.                 in-progress request handling.
  5591.  
  5592. 0x4500010F -
  5593.                 NotifyVmtpClient(client,cntrl,recSeq,transact,delivery,code)->()
  5594.                 
  5595.                 Update the state associated with the transaction
  5596.                 specified by client and transact, an entity identifier
  5597.                 and transaction identifier, respectively.  This
  5598.                 operation is normally used only by another VMTP
  5599.                 management module.  (Note that it is a datagram
  5600.                 operation.)  The other parameters are as follows:
  5601.  
  5602.                 ctrl            A 32-bit value corresponding to 4th
  5603.                                 32-bit word of the VMTP header of a
  5604.                                 Response packet that would be sent in
  5605.                                 response to the Request that this is
  5606.                                 responding to.  That is, the control
  5607.                                 flags, ForwardCount, RetransmitCount and
  5608.                                 Priority fields match those of the
  5609.                                 Request.  (The NRS flag is set if the
  5610.                                 receiveSeqNumber field is used.)  The
  5611.                                 PGCount subfield indicates the number of
  5612.                                 previous Request packet groups being
  5613.                                 acknowledged by this Notify operation.
  5614.                                 (The bit fields that are reserved in
  5615.  
  5616.  
  5617. Cheriton                                                       [page 96]
  5618.  
  5619.  
  5620.  
  5621. RFC 1045                       VMTP                        February 1988 
  5622.  
  5623.  
  5624.                                 this word in the header are also
  5625.                                 reserved here and must be zero.)
  5626.  
  5627.                 recSeq          Sequence number of reception at the
  5628.                                 Server if the NRS flag is set in the
  5629.                                 ctrl parameter, otherwise reserved and
  5630.                                 zero.  (This is used for sender-based
  5631.                                 logging of message activity for replay
  5632.                                 in case of failure - an optional
  5633.                                 facility.)
  5634.  
  5635.                 delivery        Indicates the segment blocks of the
  5636.                                 packet group have been received at the
  5637.                                 Server.
  5638.  
  5639.                 code            indicates the action the client should
  5640.                                 take, as described below.
  5641.  
  5642.                 The VMTP management module should take action on this
  5643.                 operation according to the code, as specified below.
  5644.  
  5645.                 OK              Do nothing at this time, continue
  5646.                                 waiting for the response with a reset
  5647.                                 timer.
  5648.  
  5649.                 RETRY           Retransmit the request packet group
  5650.                                 immediately with at least the segment
  5651.                                 blocks that the Server failed to
  5652.                                 receive, the complement of those
  5653.                                 indicated by the delivery parameter.
  5654.  
  5655.                 RETRY_ALL       Retransmit the request packet group
  5656.                                 immediately with at least the segment
  5657.                                 blocks that the Server failed to
  5658.                                 receive, as indicated by the delivery
  5659.                                 field plus all subsequently transmitted
  5660.                                 packets that are part of this packet
  5661.                                 run.  (The latter is applicable only for
  5662.                                 streamed message transactions.)
  5663.  
  5664.                 BUSY            The server was unable to accept the
  5665.                                 Request at this time.  Retry later if
  5666.                                 desired to continue with the message
  5667.                                 transaction.
  5668.  
  5669.                 NONEXISTENT_ENTITY
  5670.                                 Specified Server entity does not exist.
  5671.  
  5672.  
  5673. Cheriton                                                       [page 97]
  5674.  
  5675.  
  5676.  
  5677. RFC 1045                       VMTP                        February 1988 
  5678.  
  5679.  
  5680.                 ENTITY_MIGRATED The server entity has migrated and is no
  5681.                                 longer at the host to which the request
  5682.                                 was sent.  The Server should attempt to
  5683.                                 determine the new host address of the
  5684.                                 Client using the VMTP management
  5685.                                 ProbeEntity operation (described
  5686.                                 earlier).
  5687.  
  5688.                 NO_PERMISSION   Server has not authorized reception of
  5689.                                 messages from this client.
  5690.  
  5691.                 NOT_AWAITING_MSG
  5692.                                 The conditional message delivery bit was
  5693.                                 set for the Request packet group and the
  5694.                                 Server was not waiting for it so the
  5695.                                 Request packet group was discarded.
  5696.  
  5697.                 VMTP_ERROR      The Request packet group was in error
  5698.                                 relative to the VMTP protocol
  5699.                                 specification.
  5700.  
  5701.                 BAD_TRANSACTION_ID
  5702.                                 Transaction identifier is old relative
  5703.                                 to the transaction identifier held for
  5704.                                 the Client by the Server.
  5705.  
  5706.                 STREAMING_NOT_SUPPORTED
  5707.                                 Server does not support multiple
  5708.                                 outstanding message transactions from
  5709.                                 the same Client, i.e. streamed message
  5710.                                 transactions.
  5711.  
  5712.                 SECURITY_NOT_SUPPORTED
  5713.                                 The Request was secure and this Server
  5714.                                 does not support security.
  5715.  
  5716.                 SECURITY_REQUIRED
  5717.                                 The Server is refusing the Request
  5718.                                 because it was not encrypted.
  5719.  
  5720.                 NO_RUN_RECORD   Server has no record of previous packets
  5721.                                 in this run of packet groups.  This can
  5722.                                 occur if the first packet group is lost
  5723.                                 or if the current packet group is sent
  5724.                                 significantly later than the last one
  5725.                                 and the Server has discarded its client
  5726.                                 state record.
  5727.  
  5728.  
  5729. Cheriton                                                       [page 98]
  5730.  
  5731.  
  5732.  
  5733. RFC 1045                       VMTP                        February 1988 
  5734.  
  5735.  
  5736. 0x45000110 - NotifyVmtpServer(server,client,transact,delivery,code)->() 
  5737.                 Update the server state associated with the transaction
  5738.                 specified by client and transact, an entity identifier
  5739.                 and transaction identifier, respectively.  This
  5740.                 operation is normally used only by another VMTP
  5741.                 management module.  (Note that it is a datagram
  5742.                 operation.)  The other parameters are as follows:
  5743.  
  5744.                 delivery        Indicates the segment blocks of the
  5745.                                 Response packet group that have been
  5746.                                 received at the Client.
  5747.  
  5748.                 code            indicates the action the Server should
  5749.                                 take, as listed below.
  5750.  
  5751.                 The VMTP management module should take action on this
  5752.                 operation according to the code, as specified below.
  5753.  
  5754.                 OK              Client is satisfied with Response data.
  5755.                                 The Server can discard the response
  5756.                                 data, if any.
  5757.  
  5758.                 RETRY           Retransmit the Response packet group
  5759.                                 immediately with at least the segment
  5760.                                 blocks that the Client failed to
  5761.                                 receive, as indicated by the delivery
  5762.                                 parameter.  (The delivery parameter
  5763.                                 indicates those segment blocks received
  5764.                                 by the Client).
  5765.  
  5766.                 RETRY_ALL       Retransmit the Response packet group
  5767.                                 immediately with at least the segment
  5768.                                 blocks that the Client failed to
  5769.                                 receive, as indicated by the (complement
  5770.                                 of) the delivery parameter.  Also,
  5771.                                 retransmit all Response packet groups
  5772.                                 send subsequent to the specified packet
  5773.                                 group.
  5774.  
  5775.                 NONEXISTENT_ENTITY
  5776.                                 Specified Client entity does not exist.
  5777.  
  5778.                 ENTITY_MIGRATED The Client entity has migrated and is no
  5779.                                 longer at the host to which the response
  5780.                                 was sent.
  5781.  
  5782.                 RESPONSE_DISCARDED
  5783.  
  5784.  
  5785. Cheriton                                                       [page 99]
  5786.  
  5787.  
  5788.  
  5789. RFC 1045                       VMTP                        February 1988 
  5790.  
  5791.  
  5792.                                 The Response was discarded and no longer
  5793.                                 of interest to the Client.  This may
  5794.                                 occur if the conditional message
  5795.                                 delivery bit was set for the Response
  5796.                                 packet group and the Client was not
  5797.                                 waiting for it so the Response packet
  5798.                                 group was discarded.
  5799.  
  5800.                 VMTP_ERROR      The Response packet group was in error
  5801.                                 relative to the VMTP protocol
  5802.                                 specification.
  5803.  
  5804. 0x41000111 -
  5805.                 NotifyRemoteVmtpClient(client,ctrl,recSeq,transact,delivery,code->()
  5806.                 
  5807.                 The same as NotifyVmtpClient except the co-resident
  5808.                 addressing is not used.  This operation is used to
  5809.                 update client state that is remote when a Request is
  5810.                 forwarded.
  5811.  
  5812. Note the use of the CRE bit in the RequestCodes to route the request to
  5813. the correct VMTP management module(s) to handle the request.
  5814.  
  5815.  
  5816. III.1. Entity Group Management
  5817.  
  5818. An entity in a group has a set of permissions associated with its
  5819. membership, controling whether it can add or remove others, whether it
  5820. can remove itself, and whether others can remove it from the group.  The
  5821. permissions for entity groups are as follows:
  5822. VMTP_GRP_MANAGER    0x00000001 { Manager of group. }
  5823. VMTP_REM_BY_SELF    0x00000002 { Can be removed self. }
  5824. VMTP_REM_BY_PRIN    0x00000004 { Can be rem'ed by same principal}
  5825. VMTP_REM_BY_OTHE    0x00000008 { Can be removed any others. }
  5826. VMTP_ADD_PRIN       0x00000010 { Can add by same principal. }
  5827. VMTP_ADD_OTHE       0x00000020 { Can add any others. }
  5828. VMTP_REM_PRIN       0x00000040 { Can remove same principal. }
  5829. VMTP_REM_OTHE       0x00000080 { Can remove any others. }
  5830.  
  5831. To remove an entity from a restricted group, the invoker must have
  5832. permission to remove that entity and the entity must have permissions
  5833. that allow it to be removed by that entity.  With an unrestricted group,
  5834. only the latter condition applies.
  5835.  
  5836. With a restricted group, a member can only be added by another entity
  5837. with the permissions to add other entities.  The creator of a group is
  5838. given full permissions on a group.  A entity adding another entity to a
  5839.  
  5840.  
  5841. Cheriton                                                      [page 100]
  5842.  
  5843.  
  5844.  
  5845. RFC 1045                       VMTP                        February 1988 
  5846.  
  5847.  
  5848. group can only give the entity it adds a subset of its permissions.
  5849. With unrestricted groups, any entity can add itself to the group.  It
  5850. can also add other entities to the group providing the entity is not
  5851. marked as immune to such requests.  (This is an implementation
  5852. restriction that individual entities can impose.)
  5853.  
  5854.  
  5855. III.2. VMTP Management Digital Signatures
  5856.  
  5857. As mentioned above, the entityId field of the AddToGroup and
  5858. RemoveFromGroup is used to transmit a digital signature indicating the
  5859. permission for the operation has been checked by the sending kernel.
  5860. The digital signature procedures have not yet been defined.  This field
  5861. should be set to 0 for now to indicate no signature after the CREntity
  5862. parameter is set to the entity on which the operation is to be
  5863. performed.
  5864.  
  5865.  
  5866.  
  5867.  
  5868.  
  5869.  
  5870.  
  5871.  
  5872.  
  5873.  
  5874.  
  5875.  
  5876.  
  5877.  
  5878.  
  5879.  
  5880.  
  5881.  
  5882.  
  5883.  
  5884.  
  5885.  
  5886.  
  5887.  
  5888.  
  5889.  
  5890.  
  5891.  
  5892.  
  5893.  
  5894.  
  5895.  
  5896.  
  5897. Cheriton                                                      [page 101]
  5898.  
  5899.  
  5900.  
  5901. RFC 1045                       VMTP                        February 1988 
  5902.  
  5903.  
  5904. IV. VMTP Entity Identifier Domains
  5905.  
  5906. VMTP allows for several disjoint naming domains for its endpoints.  The
  5907. 64-bit entity identifier is only unique and meaningful within its
  5908. domain.  Each domain can define its own algorithm or mechanism for
  5909. assignment of entity identifiers, although each domain mechanism must
  5910. ensure uniqueness, stability of identifiers and host independence.
  5911.  
  5912.  
  5913. IV.1. Domain 1
  5914.  
  5915. For initial use of VMTP, we define the domain with Domain identifier 1
  5916. as follows:
  5917.  
  5918.  +-----------+----------------+------------------------+
  5919.  | TypeFlags | Discriminator  |    Internet Address    |
  5920.  +-----------+----------------+------------------------+
  5921.     4 bits          28 bits                32 bits
  5922.  
  5923. The Internet address is the Internet address of the host on which this
  5924. entity-id is originally allocated.  The Discriminator is an arbitrary
  5925. value that is unique relative to this Internet host address.  In
  5926. addition, the host must guarantee that this identifier does not get
  5927. reused for a long period of time after it becomes invalid.  ("Invalid"
  5928. means that no VMTP module considers in bound to an entity.)  One
  5929. technique is to use the lower order bits of a 1 second clock.  The clock
  5930. need not represent real-time but must never be set back after a crash.
  5931. In a simple implementation, using the low order bits of a clock as the
  5932. time stamp, the generation of unique identifiers is overall limited to
  5933. no more than 1 per second on average.  The type flags were described in
  5934. Section 3.1.
  5935.  
  5936. An entity may migrate between hosts.  Thus, an implementation can
  5937. heuristically use the embedded Internet address to locate an entity but
  5938. should be prepared to maintain a cache of redirects for migrated
  5939. entities, plus accept Notify operations indicating that migration has
  5940. occurred.
  5941.  
  5942. Entity group identifiers in Domain 1 are structured in one of two forms,
  5943. depending on whether they are well-known or dynamically allocated
  5944. identifiers.  A well-known entity identifier is structured as:
  5945.  
  5946.  +-----------+----------------+------------------------+
  5947.  | TypeFlags |  Discriminator |Internet Host Group Addr|
  5948.  +-----------+----------------+------------------------+
  5949.     4 bits          28 bits                32 bits
  5950.  
  5951.  
  5952.  
  5953. Cheriton                                                      [page 102]
  5954.  
  5955.  
  5956.  
  5957. RFC 1045                       VMTP                        February 1988 
  5958.  
  5959.  
  5960. with the second high-order bit (GRP) set to 1.  This form of entity
  5961. identifier is mapped to the Internet host group address specified in the
  5962. low-order 32 bits.  The Discriminator distinguishes group identifiers
  5963. using the same Internet host group.  Well-known entity group identifiers
  5964. should be allocated to correspond to the basic services provided by
  5965. hosts that are members of the group, not specifically because that
  5966. service is provided by VMTP.  For example, the well-known entity group
  5967. identifier for the domain name service should contain as its embedded
  5968. Internet host group address the host group for Domain Name servers.
  5969.  
  5970. A dynamically allocated entity identifier is structured as:
  5971.  
  5972.  +-----------+----------------+------------------------+
  5973.  | TypeFlags |  Discriminator |   Internet Host Addr   |
  5974.  +-----------+----------------+------------------------+
  5975.     4 bits          28 bits             32 bits
  5976.  
  5977. with the second high-order bit (GRP) set to 1.  The Internet address in
  5978. the low-order 32 bits is a Internet address assigned to the host that
  5979. dynamically allocates this entity group identifier.  A dynamically
  5980. allocated entity group identifier is mapped to Internet host group
  5981. address 232.X.X.X where X.X.X are the low-order 24 bits of the
  5982. Discriminator subfield of the entity group identifier.
  5983.  
  5984. We use the following notation for Domain 1 entity identifiers <10> and
  5985. propose it use as a standard convention.
  5986.  
  5987.         <flags>-<discriminator>-<Internet address>
  5988.  
  5989. where <flags> are [X]{BE,LE,RG,UG}[A]
  5990.  
  5991.     X = reserved
  5992.     BE = big-endian entity
  5993.     LE = little-endian entity
  5994.     RG = restricted group
  5995.     UG = unrestricted group
  5996.     A  = alias
  5997.  
  5998. and <discriminator> is a decimal integer and <Internet address> is in
  5999. standard dotted decimal IP address notation.
  6000.  
  6001. Examples:
  6002.  
  6003. _______________
  6004.  
  6005. <10>  This notation was developed by Steve Deering.
  6006.  
  6007.  
  6008. Cheriton                                                      [page 103]
  6009.  
  6010.  
  6011.  
  6012. RFC 1045                       VMTP                        February 1988 
  6013.  
  6014.  
  6015. BE-25593-36.8.0.49 is big-endian entity #25593 created on host
  6016.                 36.8.0.49.
  6017.  
  6018. RG-1-224.0.1.0 is the well-known restricted VMTP managers group.
  6019.  
  6020. UG-565338-36.8.0.77 is unrestricted entity group #565338 created on host
  6021.                 36.8.0.77.
  6022.  
  6023. LEA-7823-36.8.0.77 is a little-endian alias entity #7823 created on host
  6024.                 36.8.0.77.
  6025.  
  6026. This notation makes it easy to communicate and understand entity
  6027. identifiers for Domain 1.
  6028.  
  6029. The well-known entity identifiers specified to date are:
  6030.  
  6031. VMTP_MANAGER_GROUP   RG-1-224.0.1.0
  6032.                 Managers for VMTP operations.
  6033.  
  6034. VMTP_DEFAULT_BECLIENT  BE-1-224.0.1.0
  6035.                 Client entity identifier to use when a (big-endian) host
  6036.                 has not determined or been allocated any client entity
  6037.                 identifiers.
  6038.  
  6039. VMTP_DEFAULT_LECLIENT  LE-1-224.0.1.0
  6040.                 Client entity identifier to use when a (little-endian)
  6041.                 host has not determined or been allocated any client
  6042.                 entity identifiers.
  6043.  
  6044. Note that 224.0.1.0 is the host group address assigned to VMTP and to
  6045. which all VMTP hosts belong.
  6046.  
  6047. Other well-known entity group identifiers will be specified in
  6048. subsequent extensions to VMTP and in higher-level protocols that use
  6049. VMTP.
  6050.  
  6051.  
  6052. IV.2. Domain 3
  6053.  
  6054. Domain 3 is reserved for embedded systems that are restricted to a
  6055. single network and are independent of IP.  Entity identifiers are
  6056. allocated using the decentralized approach described below.  The mapping
  6057. of entity group identifiers is specific to the type of network being
  6058. used and not defined here.  In general, there should be a simple
  6059. algorithmic mapping from entity group identifier to multicast address,
  6060. similar to that described for Domain 1.  Similarly, the values for
  6061. default client identifier are specific to the type of network and not
  6062.  
  6063.  
  6064. Cheriton                                                      [page 104]
  6065.  
  6066.  
  6067.  
  6068. RFC 1045                       VMTP                        February 1988 
  6069.  
  6070.  
  6071. defined here.
  6072.  
  6073.  
  6074. IV.3. Other Domains
  6075.  
  6076. Definition of additional VMTP domains is planned for the future.
  6077. Requests for allocation of VMTP Domains should be addressed to the
  6078. Internet protocol administrator.
  6079.  
  6080.  
  6081. IV.4. Decentralized Entity Identifier Allocation
  6082.  
  6083. The ProbeEntityBlock operation may be used to determine whether a block
  6084. of entity identifiers is in use.  ("In use" means valid or reserved by a
  6085. host for allocation.)  This mechanism is used to detect collisions in
  6086. allocation of blocks of entity identifiers as part of the implementation
  6087. of decentralized allocation of entity identifiers.  (Decentralized
  6088. allocation is used in local domain use of VMTP such as in embedded
  6089. systems- see Domain 3.)
  6090.  
  6091. Basically, a group of hosts can form a Domain or sub-Domain, a group of
  6092. hosts managing their own entity identifier space or subspace,
  6093. respectively.  As an example of a sub-Domain, a group of hosts in Domain
  6094. 1 all identified with a particular host group address can manage the
  6095. sub-Domain corresponding to all entity identifiers that contain that
  6096. host group address.  The ProbeEntityBlock operation is used to allocate
  6097. the random bits of these identifiers as follows.
  6098.  
  6099. When a host requires a new block of entity identifiers, it selects a new
  6100. block (randomly or by some choice algorithm) and then multicasts a
  6101. ProbeEntityBlock request to the members of the (sub-)Domain some R
  6102. times.  If no response is received after R (re)transmissions, the host
  6103. concludes that it is free to use this block of identifiers.  Otherwise,
  6104. it picks another block and tries again.
  6105.  
  6106. Notes:
  6107.  
  6108.    1. A block of 256 identifiers is specified by an entity
  6109.       identifier with the low-order 8 bits all zero.
  6110.  
  6111.    2. When a host allocates an initial block of entity identifiers
  6112.       (and therefore does not yet have a specified entity
  6113.       identifier to use) it uses VMTP_DEFAULT_BECLIENT (if
  6114.       big-endian, else VMTP_DEFAULT_LECLIENT if little-endian) as
  6115.       its client identifier in the ProbeEntityBlock Request and a
  6116.       transaction identifier of 0.  As soon as it has allocated a
  6117.       block of entity identifiers, it should use these identifiers
  6118.  
  6119.  
  6120. Cheriton                                                      [page 105]
  6121.  
  6122.  
  6123.  
  6124.  RFC 1045                       VMTP                        February 1988 
  6125.  
  6126.  
  6127.       for all subsequent communication.  The default client
  6128.       identifier values are defined for each Domain.
  6129.  
  6130.    3. The set of hosts using this decentralized allocation must not
  6131.       be subject to network partitioning.  That is, the R
  6132.       transmissions must be sufficient to ensure that every host
  6133.       sees the ProbeEntityBlock request and (reliably) sends a
  6134.       response.  (A host that detects a collision can retransmit
  6135.       the response multiple times until it sees a new
  6136.       ProbeEntityBlock operation from the same host/Client up to a
  6137.       maximum number of times.)  For instance, a set of machines
  6138.       connected by a single local network may able to use this type
  6139.       of allocation.
  6140.  
  6141.    4. To guarantee T-stability, a host must prevent reuse of a
  6142.       block of identifiers if any of the identifiers in the block
  6143.       are currently valid or have been valid less than T seconds
  6144.       previously.  To this end, a host must remember recently used
  6145.       identifiers and object to their reuse in response to a
  6146.       ProbeEntityBlock operation.
  6147.  
  6148.    5. Care is required in a VMTP implementation to ensure that
  6149.       Probe operations cannot be discarded due to lack of buffer
  6150.       space or queued or delayed so that a response is not
  6151.       generated quickly.  This is required not only to detect
  6152.       collisions but also to provide accurate roundtrip estimates
  6153.       as part of ProbeEntity operations.
  6154.  
  6155.  
  6156.  
  6157.  
  6158.  
  6159.  
  6160.  
  6161.  
  6162.  
  6163.  
  6164.  
  6165.  
  6166.  
  6167.  
  6168.  
  6169.  
  6170.  
  6171.  
  6172.  
  6173.  
  6174.  
  6175.  
  6176. Cheriton                                                      [page 106]
  6177.  
  6178.  
  6179.  
  6180. RFC 1045                       VMTP                        February 1988 
  6181.  
  6182.  
  6183. V. Authentication Domains
  6184.  
  6185. A VMTP authentication domain defines the format and interpretation for
  6186. principal identifiers and encryption keys.  In particular, an
  6187. authentication domain must specify a means by which principal
  6188. identifiers are allocated and guaranteed unique and stable.  The
  6189. currently defined authentication domains are as follows (0 is reserved).
  6190.  
  6191. Ideally, all entities within one entity domain are also associated with
  6192. one authentication domain.  However, authentication domains are
  6193. orthogonal to entity domains.  Entities within one domain may have
  6194. different authentication domains.  (In this case, it is generally
  6195. necessary to have some correspondence between principals in the
  6196. different domains.)  Also, one entity identifier may be associated with
  6197. multiple authentication domains.  Finally, one authentication domain may
  6198. be used across multiple entity domains.
  6199.  
  6200.  
  6201. V.1. Authentication Domain 1
  6202.  
  6203. A principal identifier is structured as follows.
  6204.  
  6205.  +---------------------------+------------------------+
  6206.  |     Internet Address      | Local User Identifier  |
  6207.  +---------------------------+------------------------+
  6208.              32 bits                    32 bits
  6209.  
  6210. The Internet Address may specify an individual host (such as a UNIX
  6211. machine) or may specify a host group address corresponding to a cluster
  6212. of machines operating under a single adminstration.  In both cases,
  6213. there is assumed to be an adminstration associated with the embedded
  6214. Internet address that guarantees the uniqueness and stability of the
  6215. User Identifier relative to the Internet address.  In particular, that
  6216. administration is the only one authorized to allocate principal
  6217. identifiers with that Internet address prefix, and it may allocate any
  6218. of these identifiers.
  6219.  
  6220. In authentication domain 1, the standard EncryptionQualifiers are:
  6221.  
  6222. 0               Clear text - no encryption.
  6223.  
  6224. 1               use 64-bit CBC DES for encryption and decryption.
  6225.  
  6226.  
  6227. V.2. Other Authentication Domains
  6228.  
  6229. Other authentication domains will be defined in the future as needed.
  6230.  
  6231.  
  6232.  
  6233. Cheriton                                                      [page 107]
  6234.  
  6235.  
  6236.  
  6237. RFC 1045                       VMTP                        February 1988 
  6238.  
  6239.  
  6240. VI. IP Implementation
  6241.  
  6242. VMTP is designed to be implemented on the DoD IP Internet Datagram
  6243. Protocol (although it may also be implemented as a local network
  6244. protocol directly in "raw" network packets.)
  6245.  
  6246. VMTP is assigned the protocol number 81.
  6247.  
  6248. With a 20 octet IP header and one segment block, a VMTP packet is 600
  6249. octets.  By convention, any host implementing VMTP implicitly agrees to
  6250. accept VMTP/IP packets of at least 600 octets.
  6251.  
  6252. VMTP multicast facilities are designed to work with, and have been
  6253. implemented using, the multicast extensions to the Internet [8]
  6254. described in RFC 966 and 988.  The wide-scale use of full VMTP/IP
  6255. depends on the availability of IP multicast in this form.
  6256.  
  6257.  
  6258.  
  6259.  
  6260.  
  6261.  
  6262.  
  6263.  
  6264.  
  6265.  
  6266.  
  6267.  
  6268.  
  6269.  
  6270.  
  6271.  
  6272.  
  6273.  
  6274.  
  6275.  
  6276.  
  6277.  
  6278.  
  6279.  
  6280.  
  6281.  
  6282.  
  6283.  
  6284.  
  6285.  
  6286.  
  6287.  
  6288.  
  6289. Cheriton                                                      [page 108]
  6290.  
  6291.  
  6292.  
  6293. RFC 1045                       VMTP                        February 1988 
  6294.  
  6295.  
  6296. VII. Implementation Notes
  6297.  
  6298. The performance and reliability of a protocol in operation is highly
  6299. dependent on the quality of its implementation, in addition to the
  6300. "intrinsic" quality of the protocol design.  One of the design goals of
  6301. the VMTP effort was to produce an efficiently implementable protocol.
  6302. The following notes and suggestions are based on experience with
  6303. implementing VMTP in the V distributed system and the UNIX 4.3 BSD
  6304. kernel.  The following is described for a client and server handling
  6305. only one domain.  A multi-domain client or server would replicate these
  6306. structures for each domain, although buffer space may be shared.
  6307.  
  6308.  
  6309. VII.1. Mapping Data Structures
  6310.  
  6311. The ClientMap procedure is implemented using a hash table that maps to
  6312. the Client State Record whether this entity is local or remote, as shown
  6313. in Figure VII-1.
  6314.  
  6315.              +---+---+--------------------------+
  6316.  ClientMap   |   | x |                          |
  6317.              +---+-|-+--------------------------+
  6318.                    |   +--------------+    +--------------+
  6319.                    +-->| LocalClient  |--->| LocalClient  |
  6320.                        +--------------+    +--------------+
  6321.                        | RemoteClient |    | RemoteClient |-> ...
  6322.                        +--------------+    +--------------+
  6323.                        |              |    |              |
  6324.                        |              |    |              |
  6325.                        +--------------+    +--------------+
  6326.  
  6327.             Figure VII-1:   Mapping Client Identifier to CSR
  6328.  
  6329. Local clients are linked through the LocalClientLink, similarly for the
  6330. RemoteClientLink.  Once a CSR with the specified Entity Id is found,
  6331. some field or flag indicates whether it is identifying a local or remote
  6332. Entity.  Hash collisions are handled with the overflow pointers
  6333. LocalClientLink and RemoteClientLink (not shown) in the CSR for the
  6334. LocalClient and RemoteClient fields, respectively.  Note that a CSR
  6335. representing an RPC request has both a local and remote entity
  6336. identifier mapping to the same CSR.
  6337.  
  6338. The Server specified in a Request is mapped to a server descriptor using
  6339. the ServerMap (with collisions handled by the overflow pointer.).  The
  6340. server descriptor is the root of a queue of CSR's for handling requests
  6341. plus flags that modify the handling of the Request.  Flags include:
  6342.  
  6343.  
  6344.  
  6345. Cheriton                                                      [page 109]
  6346.  
  6347.  
  6348.  
  6349. RFC 1045                       VMTP                        February 1988 
  6350.  
  6351.  
  6352.                  +-------+---+-------------------------+
  6353.   ServerMap      |       | x |                         |
  6354.                  +-------+-|-+-------------------------+
  6355.                            |   +--------------+
  6356.                            |   | OverflowLink |
  6357.                            |   +--------------+
  6358.                            +-->|   Server     |
  6359.                                +--------------+
  6360.                                | Flags | Lock |
  6361.                                +--------------+
  6362.                                | Head Pointer |
  6363.                                +--------------+
  6364.                                | Tail Pointer |
  6365.                                +--------------+
  6366.  
  6367.                Figure VII-2:   Mapping Server Identifiers
  6368.  
  6369. THREAD_QUEUE    Request is to be invoked directly as a remote procedure
  6370.                 invocation, rather than by a server process in the
  6371.                 message model.
  6372.  
  6373. AUTHENTICATION_REQUIRED
  6374.                 Sent a Probe request to determine principal associated
  6375.                 with the Client, if not known.
  6376.  
  6377. SECURITY_REQUIRED
  6378.                 Request must be encrypted or else reject.
  6379.  
  6380. REQUESTS_QUEUED Queue contains waiting requests, rather than free CSR's.
  6381.                 Queue this request as well.
  6382.  
  6383. SERVER_WAITING  The server is waiting and available to handle incoming
  6384.                 Request immediately, as required by CMD.
  6385.  
  6386. Alternatively, the Server identifiers can be mapped to a CSR using the
  6387. MapToClient mechanism with a pointer in the CSR refering to the server
  6388. descriptor, if any.  This scheme is attractive if there are client CSR's
  6389. associated with a service to allow it to communicate as a client using
  6390. VMTP with other services.
  6391.  
  6392. Finally, a similar structure is used to expand entity group identifiers
  6393. to the local membership, as shown in Figure VII-3.  A group identifier
  6394. is hashed to an index in the GroupMap.  The list of group descriptors
  6395. rooted at that index in the GroupMap contains a group descriptor for
  6396. each local member of the group.  The flags are the group permissions
  6397. defined in Appendix III.
  6398.  
  6399.  
  6400.  
  6401. Cheriton                                                      [page 110]
  6402.  
  6403.  
  6404.  
  6405. RFC 1045                       VMTP                        February 1988 
  6406.  
  6407.  
  6408.                  +-------+---+----------------------------------+
  6409.   GroupMap       |       | x |                                  |
  6410.                  +-------+-|-+----------------------------------+
  6411.                            |   +--------------+
  6412.                            |   | OverflowLink |
  6413.                            |   +--------------+
  6414.                            +-->|EntityGroupId |
  6415.                                +--------------+
  6416.                                | Flags        |
  6417.                                +--------------+
  6418.                                | Member Entity|
  6419.                                +--------------+
  6420.  
  6421.                Figure VII-3:   Mapping Group Identifiers
  6422.  
  6423. Note that the same pool of descriptors could be used for the server and
  6424. group descriptors given that they are similar in size.
  6425.  
  6426.  
  6427. VII.2. Client Data Structures
  6428.  
  6429. Each client entity is represented as a client state record.  The CSR
  6430. contains a VMTP header as well as other bookkeeping fields, including
  6431. timeout count, retransmission count, as described in Section 4.1.  In
  6432. addition, there is a timeout queue, transmission queue and reception
  6433. queue.  Finally, there is a ServerHost cache that maps from server
  6434. entity-id records to host address, estimated round trip time,
  6435. interpacket gap, MTU size and (optimally) estimated processing time for
  6436. this server entity.
  6437.  
  6438.  
  6439. VII.3. Server Data Structures
  6440.  
  6441. The server maintains a heap of client state records (CSR), one for each
  6442. (Client, Transaction).  (If streams are not supported, there is, at
  6443. worst, a CSR per Client with which the server has communicated with
  6444. recently.)  The CSR contains a VMTP header as well as various
  6445. bookkeeping fields including timeout count, retransmission count.  The
  6446. server maintains a hash table mapping of Client to CSR as well as the
  6447. transmission, timeout and reception queues.  In a VMTP module
  6448. implementing both the client and server functions, the same timeout
  6449. queue and transmission queue are used for both.
  6450.  
  6451.  
  6452.  
  6453.  
  6454.  
  6455.  
  6456.  
  6457. Cheriton                                                      [page 111]
  6458.  
  6459.  
  6460.  
  6461. RFC 1045                       VMTP                        February 1988 
  6462.  
  6463.  
  6464. VII.4. Packet Group transmission
  6465.  
  6466. The procedure SendPacketGroup( csr ) transmits the packet group
  6467. specified by the record CSR.  It performs:
  6468.  
  6469.    1. Fragmentation of the segment data, if any, into packets.
  6470.       (Note, segment data flagged by SDA bit.)
  6471.  
  6472.    2. Modifies the VMTP header for each packet as required e.g.
  6473.       changing the delivery mask as appropriate.
  6474.  
  6475.    3. Computes the VMTP checksum.
  6476.  
  6477.    4. Encrypts the appropriate portion of the packet, if required.
  6478.  
  6479.    5. Prepends and appends network-level header and trailer using
  6480.       network address from ServerHost cache, or from the responding
  6481.       CSR.
  6482.  
  6483.    6. Transmits the packet with the interpacket gap specified in
  6484.       the cache.  This may involve round-robin scheduling between
  6485.       hosts as well as delaying transmissions slightly.
  6486.  
  6487.    7. Invokes the finish-up procedure specified by the CSR record,
  6488.       completing the processing.  Generally, this finish-up
  6489.       procedure adds the record to the timeout queue with the
  6490.       appropriate timeout queue.
  6491.  
  6492. The CSR includes a 32-bit transmission mask that indicates the portions
  6493. of the segment to transmit.  The SendPacketGroup procedure is assumed to
  6494. handle queuing at the network transmission queue, queuing in priority
  6495. order according to the priority field specified in the CSR record.
  6496. (This priority may be reflected in network transmission behavior for
  6497. networks that support priority.)
  6498.  
  6499. The SendPacketGroup procedure only looks at the following fields of a
  6500. CSR
  6501.  
  6502.    - Transmission mask
  6503.  
  6504.    - FuncCode
  6505.  
  6506.    - SDA
  6507.  
  6508.    - Client
  6509.  
  6510.    - Server
  6511.  
  6512.  
  6513. Cheriton                                                      [page 112]
  6514.  
  6515.  
  6516.  
  6517. RFC 1045                       VMTP                        February 1988 
  6518.  
  6519.  
  6520.    - CoResidentEntity
  6521.  
  6522.    - Key
  6523.  
  6524. It modifies the following fields
  6525.  
  6526.    - Length
  6527.  
  6528.    - Delivery
  6529.  
  6530.    - Checksum
  6531.  
  6532. In the case of encrypted transmission, it encrypts the entire packet,
  6533. not including the Client field and the following 32-bits.
  6534.  
  6535. If the packet group is a Response, (i.e. lower-order bit of function
  6536. code is 1) the destination network address is determined from the
  6537. Client, otherwise the Server.  The HostAddr field is set either from the
  6538. ServerHost cache (if a Request) or from the original Request if a
  6539. Response, before SendPacketGroup is called.
  6540.  
  6541. The CSR includes a timeout and TTL fields indicating the maximum time to
  6542. complete the processing and the time-to-live for the packets to be
  6543. transmitted.
  6544.  
  6545. SendPacketGroup is viewed as the right functionality to implement for
  6546. transmission in an "intelligent" network interface.
  6547.  
  6548. Finally, it appears preferable to be able to assume that all portions of
  6549. the segment remain memory-resident (no page faults) during transmission.
  6550. In a demand-paged systems, some form of locking is required to keep the
  6551. segment data in memory.
  6552.  
  6553.  
  6554. VII.5. VMTP Management Module
  6555.  
  6556. The implementation should implement the management operations as a
  6557. separate module that is invoked from within the VMTP module.  When a
  6558. Request is received, either from the local user level or the network,
  6559. for the VMTP management module, the management module is invoked as a
  6560. remote or local procedure call to handle this request and return a
  6561. response (if not a datagram request).  By registering as a local server,
  6562. the management module should minimize the special-case code required for
  6563. its invocation.  The management module is basically a case statement
  6564. that selects the operation based on the RequestCode and then invokes the
  6565. specified management operation.  The procedure implementing the
  6566. management operation, especially operations like NotifyVmtpClient and
  6567.  
  6568.  
  6569. Cheriton                                                      [page 113]
  6570.  
  6571.  
  6572.  
  6573. RFC 1045                       VMTP                        February 1988 
  6574.  
  6575.  
  6576. NotifyVmtpServer, are logically part of the VMTP module because they
  6577. require full access to the basic data structures of the VMTP
  6578. implementation.
  6579.  
  6580. The management module should be implemented so that it can respond
  6581. quickly to all requests, particularly since the timing of management
  6582. interactions is used to estimate round trip time.  To date, all
  6583. implementations of the management module have been done at the kernel
  6584. level, along with VMTP proper.
  6585.  
  6586.  
  6587. VII.6. Timeout Handling
  6588.  
  6589. The timeout queue is a queue of CSR records, ordered by timeout count,
  6590. as specified in the CSR record.  On entry into the timeout queue, the
  6591. CSR record has the timeout field set to the time (preferable in
  6592. milliseconds or similar unit) to remain in the queue plus the finishup
  6593. field set to the procedure to execute on removal on timeout from the
  6594. queue.  The timeout field for a CSR in the queue is the time relative to
  6595. the record preceding it in the queue (if any) at which it is to be
  6596. removed.  Some system-specific mechanism decrements the time for the
  6597. record at the front of the queue, invoking the finishup procedure when
  6598. the count goes to zero.
  6599.  
  6600. Using this scheme, a special CSR is used to timeout and scan CSR's for
  6601. non-recently pinged CSR's.  That is, this CSR times out and invokes a
  6602. finishup procedure that scans for non-recently pinged CSR that are
  6603. "AwaitingResponse" and signals the request processing entity and deletes
  6604. the CSR.  It then returns to the timeout queue.
  6605.  
  6606. The timeout mechanism tends to be specific to an operating system.  The
  6607. scheme described may have to be adapted to the operating system in which
  6608. VMTP is to be implemented.
  6609.  
  6610. This mechanism handles client request timeout and client response
  6611. timeout.  It is not intended to handle interpacket gaps given that these
  6612. times are expected to be under 1 millisecond in general and possibly
  6613. only a few microseconds.
  6614.  
  6615.  
  6616. VII.7. Timeout Values
  6617.  
  6618. Roundtrip timeout values are estimated by matching Responses or
  6619. NotifyVmtpClient Requests to Request transmission, relying on the
  6620. retransmitCount to identify the particular transmission of the Request
  6621. that generated the response.  A similar technique can be used with
  6622. Responses and NotifyVmtpServer Requests.  The retransmitCount is
  6623.  
  6624.  
  6625. Cheriton                                                      [page 114]
  6626.  
  6627.  
  6628.  
  6629. RFC 1045                       VMTP                        February 1988 
  6630.  
  6631.  
  6632. incremented each time the Response is sent, whether the retransmission
  6633. was caused by timeout or retransmission of the Request.
  6634.  
  6635. The ProbeEntity request is recommended as a basic way of getting
  6636. up-to-date information about a Client as well as predictable host
  6637. machine turnaround in processing a request.  (VMTP assumes and requires
  6638. an efficient, bounded response time implementation of the ProbeEntity
  6639. operation.)
  6640.  
  6641. Using this mechanism for measuring RTT, it is recommended that the
  6642. various estimation and smoothing techniques developed for TCP RTT
  6643. estimation be adapted and used.
  6644.  
  6645.  
  6646. VII.8. Packet Reception
  6647.  
  6648. Logically a network packet containing a VMTP packet is 5 portions:
  6649.  
  6650.    - network header, possibly including lower-level headers
  6651.  
  6652.    - VMTP header
  6653.  
  6654.    - data segment
  6655.  
  6656.    - VMTP checksum
  6657.  
  6658.    - network trailer, etc.
  6659.  
  6660. It may be advantageous to receive a packet fragmented into these
  6661. portions, if supported by the network module.  In this case, ideally the
  6662. VMTP header may be received directly into a CSR, the data segment into a
  6663. page that can be mapped, rather than copied, to its final destination,
  6664. with VMTP checksum and network header in a separate area (used to
  6665. extract the network address corresponding to the sender).
  6666.  
  6667. Packet reception is described in detail by the pseudo-code in Section
  6668. 4.7.
  6669.  
  6670. With a response, normally the CSR has an associated segment area
  6671. immediately available so delivery of segment data is immediate.
  6672. Similarly, server entities should be "armed" with CSR's with segment
  6673. areas that provide for immediate delivery of requests.  It is reasonable
  6674. to discard segment data that cannot be immediately delivered in this
  6675. way, providing that clients and servers are able to preallocate CSR's
  6676. with segment areas for requests and responses.  In particular, a client
  6677. should be able to provide some number of additional CSR's for receiving
  6678. multiple responses to a multicast request.
  6679.  
  6680.  
  6681. Cheriton                                                      [page 115]
  6682.  
  6683.  
  6684.  
  6685. RFC 1045                       VMTP                        February 1988 
  6686.  
  6687.  
  6688. The CSR data structure is intended to be the interface data structure
  6689. for an intelligent network interface.  For reception, the interface is
  6690. "armed" with CSR's that may point to segment areas in main memory, into
  6691. which it can deliver a packet group.  Ideally, the interface handles all
  6692. the processing of all packets, interacting with the host after receiving
  6693. a complete Request or Response packet group.  An implementation should
  6694. use an interface based on SendPacketGroup(CSR) and
  6695. ReceivePacketGroup(CSR) to facilitate the introduction of an intelligent
  6696. network interface.
  6697.  
  6698. ReceivePacketGroup(csr) provides the interface with a CSR descriptor and
  6699. zero or more bytes of main memory to receive segment data.  The CSR
  6700. describes whether it is to receive responses (and if so, for which
  6701. client) or requests (and if so for which server).
  6702.  
  6703. The procedure ReclaimCSR(CSR) reclaims the specified record from the
  6704. interface before it has been returned after receiving the specified
  6705. packet group.
  6706.  
  6707. A finishup procedure is set in the CSR to be invoked when the CSR is
  6708. returned to the host by the normal processing sequence in the interface.
  6709. Similarly, the timeout parameter is set to indicate the maximum time the
  6710. host is providing for the routine to perform the specified function.
  6711. The CSR and associated segment memory is returned to the host after the
  6712. timeout period with an indication of progress after the timeout period.
  6713. It is not returned earlier.
  6714.  
  6715.  
  6716. VII.9. Streaming
  6717.  
  6718. The implementation of streaming is optional in both VMTP clients and
  6719. servers.  Ideally, all performance-critical servers should implement
  6720. streaming.  In addition, clients that have high context switch overhead,
  6721. network access overhead or expect to be communicating over long delay
  6722. links should also implement streaming.
  6723.  
  6724. A client stream is implemented by allocating a CSR for each outstanding
  6725. message transaction.  A stream of transactions is handled similarly to
  6726. multiple outstanding transactions from separate clients except for the
  6727. interaction between consecutive numbered transactions in a stream.
  6728.  
  6729. For the server VMTP module, streamed message transactions to a server
  6730. are queued (if accepted) subordinate to the first unprocessed CSR
  6731. corresponding to this Client.  Thus, streamed transactions from a given
  6732. Client are always performed in the order specified by the transaction
  6733. identifiers.
  6734.  
  6735.  
  6736.  
  6737. Cheriton                                                      [page 116]
  6738.  
  6739.  
  6740.  
  6741. RFC 1045                       VMTP                        February 1988 
  6742.  
  6743.  
  6744. If a server does not implement streaming, it must refuse streamed
  6745. message transactions using the NotifyVmtpClient operation.  Also, all
  6746. client VMTP's that support streaming must support the streamed interface
  6747. to a server that does not support streaming.  That is, it must perform
  6748. the message transactions one at a time.  Consequently, a program that
  6749. uses the streaming interface to a non-streaming server experiences
  6750. degraded performance, but not failure.
  6751.  
  6752.  
  6753. VII.10. Implementation Experience
  6754.  
  6755. The implementation experience to date includes a partial implementation
  6756. (minus the streaming and full security) in the V kernel plus a similar
  6757. preliminary implementation in the 4.3 BSD Unix kernel.  In the V kernel
  6758. implementation, the CSR's are part of the (lightweight) process
  6759. descriptor.
  6760.  
  6761. The V kernel implementation is able to perform a VMTP message
  6762. transaction with no data segment between two Sun-3/75's connected by 10
  6763. Mb Ethernet in 2.25 milliseconds.  It is also able to transfer data at
  6764. 4.7 megabits per second using 16 kilobyte Requests (but null checksums.)
  6765. The UNIX kernel implementation running on Microvax II's achieves a basic
  6766. message transaction time of 9 milliseconds and data rate of 1.9 megabits
  6767. per second using 16 kilobyte Responses.  This implementation is using
  6768. the standard VMTP checksum.
  6769.  
  6770. We hope to report more extensive implementation experience in future
  6771. revisions of this document.
  6772.  
  6773.  
  6774.  
  6775.  
  6776.  
  6777.  
  6778.  
  6779.  
  6780.  
  6781.  
  6782.  
  6783.  
  6784.  
  6785.  
  6786.  
  6787.  
  6788.  
  6789.  
  6790.  
  6791.  
  6792.  
  6793. Cheriton                                                      [page 117]
  6794.  
  6795.  
  6796.  
  6797. RFC 1045                       VMTP                        February 1988 
  6798.  
  6799.  
  6800. VIII. UNIX 4.3 BSD Kernel Interface for VMTP
  6801.  
  6802. UNIX 4.3 BSD includes a socket-based design for program interfaces to a
  6803. variety of protocol families and types of protocols (streams,
  6804. datagrams).  In this appendix, we sketch an extension to this design to
  6805. support a transaction-style protocol.  (Some familiarity with UNIX 4.2/3
  6806. IPC is assumed.)  Several extensions are required to the system
  6807. interface, rather than just adding a protocol, because no provision was
  6808. made for supporting transaction protocols in the original design.  These
  6809. extensions include a new "transaction" type of socket plus new system
  6810. calls invoke, getreply, probeentity, recreq, sendreply and forward.
  6811.  
  6812. A socket of type transaction bound to the VMTP protocol type
  6813. IPPROTO_VMTP is created by the call 
  6814.  
  6815.     s = socket(AF_INET, SOCK_TRANSACT, VMTP);
  6816.  
  6817. This socket is bound to an entity identifier by 
  6818.  
  6819.     bind(s, &entityid, sizeof(entityid));
  6820.  
  6821. The first address/port bound to a socket is considered its primary name
  6822. and is the one used on packet transmission.  A message transaction is
  6823. invoked between the socket named by s and the Server specified by mcb by
  6824.  
  6825.     invoke(s, mcb, segptr, seglen, timeout );
  6826.  
  6827. The mcb is a message control block whose format was described in Section
  6828. 2.4.  The message control block specifies the request to send plus the
  6829. destination Server.  The response message control block returned by the
  6830. server is stored in mcb when invoke returns.  The invoking process is
  6831. blocked until a response is received or the message transaction times
  6832. out unless the request is a datagram request.  (Non-blocking versions
  6833. with signals on completion could also be provided, especially with a
  6834. streaming implementation.)
  6835.  
  6836. For multicast message transactions (sent to an entity group), the next
  6837. response to the current message transaction (if it arrives in less than
  6838. timeout milliseconds) is returned by 
  6839.  
  6840.     getreply( s, mcb, segptr, maxseglen, timeout );
  6841.  
  6842. The invoke operation sent to an entity group completes as soon as the
  6843. first response is received.  A request is retransmitted until the first
  6844. reply is received (assuming the request is not a datagram).  Thus, the
  6845. system does not retransmit while getreply is timing out even if no
  6846. replies are available.
  6847.  
  6848.  
  6849. Cheriton                                                      [page 118]
  6850.  
  6851.  
  6852.  
  6853. RFC 1045                       VMTP                        February 1988 
  6854.  
  6855.  
  6856. The state of an entity associated with entityId is probed using 
  6857.  
  6858.     probeentity( entityId, state );
  6859.  
  6860. A UNIX process acting as a VMTP server accepts a Request by the
  6861. operation 
  6862.  
  6863.     recvreq(s, mcb, segptr, maxseglen );
  6864.  
  6865. The request message for the next queued transaction request is returned
  6866. in mcb, plus the segment data of maximum length maxseglen, starting at
  6867. segptr in the address space.  On return, the message control block
  6868. contains the values as set in invoke except: (1) the Client field
  6869. indicates the Client that sent the received Request message.  (2) the
  6870. Code field indicates the type of request.  (3) the MsgDelivery field
  6871. indicates the portions of the segment actually received within the
  6872. specified segment size, if MDM is 1 in the Code field.  A segment block
  6873. is marked as missing (i.e. the corresponding bit in the MsgDelivery
  6874. field is 0) unless it is received in its entirety or it is all of the
  6875. data in last segment contained in the segment.
  6876.  
  6877. To complete a transaction, the reply specified by mcb is sent to the
  6878. client specified by the MCB using 
  6879.  
  6880.     sendreply(s, mcb, segptr );
  6881.  
  6882. The Client field of the MCB indicates the client to respond to.
  6883.  
  6884. Finally, a message transaction specified by mcb is forwarded to
  6885. newserver as though it were sent there by its original invoker using 
  6886.  
  6887.     forward(s, mcb, segptr, timeout );
  6888.  
  6889.  
  6890.  
  6891.  
  6892.  
  6893.  
  6894.  
  6895.  
  6896.  
  6897.  
  6898.  
  6899.  
  6900.  
  6901.  
  6902.  
  6903.  
  6904.  
  6905. Cheriton                                                      [page 119]
  6906.  
  6907.  
  6908.  
  6909. RFC 1045                       VMTP                        February 1988 
  6910.  
  6911.  
  6912. Index
  6913.  
  6914.           Acknowledgment   14
  6915.           APG   16, 31, 39
  6916.           Authentication domain   20
  6917.  
  6918.           Big-endian   9
  6919.  
  6920.           Checksum   14, 43
  6921.           Checksum, not set   44
  6922.           Client   7, 10, 38
  6923.           Client timer   16
  6924.           CMD   42, 110
  6925.           CMG   32, 40
  6926.           Co-resident entity   25
  6927.           Code   42
  6928.           CoResidentEntity   42, 43
  6929.           CRE   21, 42
  6930.  
  6931.           DGM   42
  6932.           Digital signature, VMTP management   95, 101
  6933.           Diskless workstations   2
  6934.           Domain   9, 38
  6935.           Domain 1   102
  6936.           Domain 3   104
  6937.  
  6938.           Entity   7
  6939.           Entity domain   9
  6940.           Entity group   8
  6941.           Entity identifier   37
  6942.           Entity identifier allocation   105
  6943.           Entity identifier, all-zero   38
  6944.           EPG   20, 39
  6945.  
  6946.           Features   6
  6947.           ForwardCount   24
  6948.           Forwarding   24
  6949.           FunctionCode   41
  6950.  
  6951.           Group   8
  6952.           Group message transaction   10
  6953.           Group timeouts   16
  6954.           GRP   37
  6955.  
  6956.           HandleNoCSR   62
  6957.           HandleRequestNoCSR   79
  6958.           HCO   14, 23, 39
  6959.  
  6960.  
  6961. Cheriton                                                      [page 120]
  6962.  
  6963.  
  6964.  
  6965. RFC 1045                       VMTP                        February 1988 
  6966.  
  6967.  
  6968.           Host independence   8
  6969.  
  6970.           Idempotent   15
  6971.           Interpacket gap   18, 40
  6972.           IP   108
  6973.  
  6974.           Key   91
  6975.  
  6976.           LEE   32, 37
  6977.           Little-endian   9
  6978.  
  6979.           MCB   118
  6980.           MDG   22, 40
  6981.           MDM   30, 42
  6982.           Message control block   118
  6983.           Message size   6
  6984.           Message transaction   7, 10
  6985.           MPG   39
  6986.           MsgDelivery   43
  6987.           MSGTRANS_OVERFLOW   27
  6988.           Multicast   4, 21, 120
  6989.           Multicast, reliable   21
  6990.  
  6991.           Naming   6
  6992.           Negative acknowledgment   31
  6993.           NER   25, 31, 39
  6994.           NRT   26, 30, 39
  6995.           NSR   25, 27, 31, 39
  6996.  
  6997.           Object-oriented   2
  6998.           Overrun   18
  6999.  
  7000.           Packet group   7, 29, 39
  7001.           Packet group run   31
  7002.           PacketDelivery   29, 31, 41
  7003.           PGcount   26, 41
  7004.           PIC   42
  7005.           Principal   11
  7006.           Priority   41
  7007.           Process   11
  7008.           ProcessId   89
  7009.           Protocol number,IP   108
  7010.  
  7011.           RAE   37
  7012.           Rate control   18
  7013.           Real-time   2, 4
  7014.           Realtime   22
  7015.  
  7016.  
  7017. Cheriton                                                      [page 121]
  7018.  
  7019.  
  7020.  
  7021. RFC 1045                       VMTP                        February 1988 
  7022.  
  7023.  
  7024.           Reliability   12
  7025.           Request message   10
  7026.           RequestAckRetries   30
  7027.           RequestRetries   15
  7028.           Response message   10
  7029.           ResponseAckRetries   31
  7030.           ResponseRetries   15
  7031.           Restricted group   8
  7032.           Retransmission   15
  7033.           RetransmitCount   17
  7034.           Roundtrip time   17
  7035.           RPC   2
  7036.           Run   31, 39
  7037.           Run, message transactions   25
  7038.  
  7039.           SDA   42
  7040.           Security   4, 19
  7041.           Segment block   41
  7042.           Segment data   43
  7043.           SegmentSize   42, 43
  7044.           Selective retransmission   18
  7045.           Server   7, 10, 41
  7046.           Server group   8
  7047.           Sockets, VMTP   118
  7048.           STI   26, 40
  7049.           Streaming   25, 55
  7050.           Strictly stable   8
  7051.           Subgroups   21
  7052.  
  7053.           T-stable   8
  7054.           TC1(Server)   16
  7055.           TC2(Server)   16
  7056.           TC3(Server)   16
  7057.           TC4   16
  7058.           TCP   2
  7059.           Timeouts   15
  7060.           Transaction   10, 41
  7061.           Transaction identification   10
  7062.           TS1(Client)   17
  7063.           TS2(Client)   17
  7064.           TS3(Client)   17
  7065.           TS4(Client)   17
  7066.           TS5(Client)   17
  7067.           Type flags   8
  7068.  
  7069.           UNIX interface   118
  7070.           Unrestricted group   8, 38
  7071.  
  7072.  
  7073. Cheriton                                                      [page 122]
  7074.  
  7075.  
  7076.  
  7077. RFC 1045                       VMTP                        February 1988 
  7078.  
  7079.  
  7080.           NotifyVmtpClient   7, 26, 27, 30
  7081.           NotifyVmtpServer   7, 14, 30
  7082.           User Data   43
  7083.  
  7084.           Version   38
  7085.           VMTP Management digital signature   95, 101
  7086.  
  7087.  
  7088.  
  7089.  
  7090.  
  7091.  
  7092.  
  7093.  
  7094.  
  7095.  
  7096.  
  7097.  
  7098.  
  7099.  
  7100.  
  7101.  
  7102.  
  7103.  
  7104.  
  7105.  
  7106.  
  7107.  
  7108.  
  7109.  
  7110.  
  7111.  
  7112.  
  7113.  
  7114.  
  7115.  
  7116.  
  7117.  
  7118.  
  7119.  
  7120.  
  7121.  
  7122.  
  7123.  
  7124.  
  7125.  
  7126.  
  7127.  
  7128.  
  7129. Cheriton                                                      [page 123]
  7130.  
  7131.